Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clang: error: version 'softfloat' in target triple 'aarch64-unknown-none-softfloat' is invalid #1255

Closed
weihanglo opened this issue Nov 1, 2024 · 3 comments · Fixed by #1252

Comments

@weihanglo
Copy link
Member

This is pretty much the same problem as #1167 due to the fact that Clang from LLVM 19 starts reporting target triple it cannot recognize.

#1176 has resolved it on Windows side by remapping, but hasn't for other target triples.

Below is a list of other possible remapping we need to do. However this is based on reading target definitions in rust-lang/rust. I am not sure how unstable it is, and whether this should be done in cc-rs.

? target triple in rustc remapped target triple in llvm
aarch64-apple-ios-sim aarch64-apple-ios-simulator
aarch64-apple-tvos-sim aarch64-apple-tvos-simulator
aarch64-apple-visionos-sim aarch64-apple-visionos-simulator
aarch64-apple-watchos-sim aarch64-apple-watchos-simulator
aarch64-nintendo-switch-freestanding aarch64-unknown-none
aarch64-pc-windows-gnullvm aarch64-pc-windows-gnu
aarch64-unknown-none-softfloat aarch64-unknown-none
aarch64-unknown-nto-qnx700 aarch64-unknown-unknown
aarch64-unknown-nto-qnx710 aarch64-unknown-unknown
arm64-apple-ios-sim arm64-apple-ios-simulator
arm64-apple-tvos-sim arm64-apple-tvos-simulator
arm64-apple-visionos-sim arm64-apple-visionos-simulator
arm64-apple-watchos-sim arm64-apple-watchos-simulator
armv7-sony-vita-newlibeabihf thumbv7a-vita-eabihf
armv7-unknown-linux-uclibceabi armv7-unknown-linux-gnueabi
armv7-unknown-linux-uclibceabihf armv7-unknown-linux-gnueabihf
avr-unknown-hurd-gnu-atmega328 avr-unknown-unknown
i586-pc-nto-qnx700 i586-pc-unknown
i686-pc-windows-gnullvm i686-pc-windows-gnu
loongarch64-unknown-none-softfloat loongarch64-unknown-none
mips64-unknown-linux-muslabi64 mips64-unknown-linux-musl
mips64el-unknown-linux-muslabi64 mips64el-unknown-linux-musl
x86_64-apple-watchos-sim x86_64-apple-watchos-simulator
x86_64-fortanix-unknown-sgx x86_64-elf
x86_64-pc-nto-qnx710 x86_64-pc-unknown
x86_64-pc-windows-gnullvm x86_64-pc-windows-gnu
armv5te-unknown-linux-uclibceabi armv5te-unknown-linux-uclibcgnueabi
csky-unknown-linux-gnuabiv2 `csky-unknown-linux-gnuabiv2
csky-unknown-linux-gnuabiv2hf ??csky-unknown-linux-gnuabiv2
mips-unknown-linux-uclibc mips-unknown-linux-uclibc
mipsel-unknown-linux-uclibc mipsel-unknown-linux-uclibc
powerpc-unknown-linux-gnuspe powerpc-unknown-linux-gnuspe
powerpc-unknown-linux-muslspe powerpc-unknown-linux-muslspe
powerpc-wrs-vxworks-spe powerpc-unknown-linux-gnuspe
x86_64-unknown-l4re-uclibc x86_64-unknown-l4re-uclibc
  • ? denotes the remapped target triple is valid in clang from LLVM 19.
Details on how these were collected

Run this script (with GNU sed):

rustc +nightly --print target-list | xargs -I {} clang --target={} hello.c 2>&1 > /dev/null | sed  -rn "s/^.*version '(.*?)' in target triple '(.*?)' is invalid\$/\2/p"

Here is the result from aarch64-apple-darwin host:

rustc 1.84.0-nightly (a0d98ff0e 2024-10-31)
binary: rustc
commit-hash: a0d98ff0e5b6e1f2c63fd26f68484792621b235c
commit-date: 2024-10-31
host: aarch64-apple-darwin
release: 1.84.0-nightly
LLVM version: 19.1.1

clang version 19.1.1
Target: arm64-apple-darwin
Thread model: posix
InstalledDir: /nix/store/izlzp31xcwkaqvv148z6ki466hgmhrpq-clang-19.1.1/bin

arm64-apple-ios-sim
arm64-apple-tvos-sim
arm64-apple-visionos-sim
arm64-apple-watchos-sim
aarch64-nintendo-switch-freestanding
aarch64-pc-windows-gnullvm
aarch64-unknown-none-softfloat
aarch64-unknown-nto-qnx700
aarch64-unknown-nto-qnx710
armv5te-unknown-linux-uclibceabi
armv7-sony-vita-newlibeabihf
armv7-unknown-linux-uclibceabi
armv7-unknown-linux-uclibceabihf
avr-unknown-hurd-gnu-atmega328
csky-unknown-linux-gnuabiv2
csky-unknown-linux-gnuabiv2hf
i586-pc-nto-qnx700
i686-pc-windows-gnullvm
loongarch64-unknown-none-softfloat
mips-unknown-linux-uclibc
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-uclibc
powerpc-unknown-linux-gnuspe
powerpc-unknown-linux-muslspe
powerpc-wrs-vxworks-spe
arm64-apple-watchos-sim
x86_64-fortanix-unknown-sgx
x86_64-pc-nto-qnx710
x86_64-pc-windows-gnullvm
x86_64-unknown-l4re-uclibc

Here is the result from x86_64-unknown-linux-gnu host:

rustc 1.84.0-nightly (a0d98ff0e 2024-10-31)
binary: rustc
commit-hash: a0d98ff0e5b6e1f2c63fd26f68484792621b235c
commit-date: 2024-10-31
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.1

clang version 19.1.1
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /nix/store/m4yb6xs0g07l0bc3c4i0klgv5lgz7g6s-clang-19.1.1/bin

aarch64-apple-ios-sim
aarch64-apple-tvos-sim
aarch64-apple-visionos-sim
aarch64-apple-watchos-sim
aarch64-nintendo-switch-freestanding
aarch64-pc-windows-gnullvm
aarch64-unknown-none-softfloat
aarch64-unknown-nto-qnx700
aarch64-unknown-nto-qnx710
armv5te-unknown-linux-uclibceabi
armv7-sony-vita-newlibeabihf
armv7-unknown-linux-uclibceabi
armv7-unknown-linux-uclibceabihf
avr-unknown-hurd-gnu-atmega328
csky-unknown-linux-gnuabiv2
csky-unknown-linux-gnuabiv2hf
i586-pc-nto-qnx700
i686-pc-windows-gnullvm
loongarch64-unknown-none-softfloat
mips-unknown-linux-uclibc
mips64-unknown-linux-muslabi64
mips64el-unknown-linux-muslabi64
mipsel-unknown-linux-uclibc
powerpc-unknown-linux-gnuspe
powerpc-unknown-linux-muslspe
powerpc-wrs-vxworks-spe
x86_64-apple-watchos-sim
x86_64-fortanix-unknown-sgx
x86_64-pc-nto-qnx710
x86_64-pc-windows-gnullvm
x86_64-unknown-l4re-uclibc

@weihanglo
Copy link
Member Author

Hmm… doesn't #1225 kinda revert the fix of #1176?

@madsmtm
Copy link
Contributor

madsmtm commented Nov 1, 2024

I think things here will be fixed by #1252?

@weihanglo
Copy link
Member Author

I think things here will be fixed by #1252?

Hmm I totally missed that PR. Looks like it. Thanks fore preparing that patch!

Feel free to close this issue :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants