about summary refs log tree commit diff
path: root/compiler/rustc_target/src/spec
AgeCommit message (Collapse)AuthorLines
2023-02-10Update the minimum external LLVM to 14Josh Stone-14/+31
2023-02-09XRay support flag in TargetOptionsOleksii Lozovskyi-0/+15
Specify where XRay is supported. I only test ARM64 and x86_64, but hey those others should work too, right? LLVM documentation says that MIPS and PPC are also supported, but I don't have the hardware, so I won't pretend. Naturally, more targets can be added later with more testing.
2023-02-02Auto merge of #106925 - ↵bors-3/+3
imWildCat:imWildCat/remove-hardcoded-ios-macbi-target-version, r=wesleywiser Remove hardcoded iOS version of clang target for Mac Catalyst ## Background From `clang` 13.x, `-target x86_64-apple-ios13.0-macabi` fails while linking: ``` = note: clang: error: invalid version number in '-target x86_64-apple-ios13.0-macabi' ``` <details> <summary>Verbose output</summary> ``` error: linking with `cc` failed: exit status: 1 | = note: LC_ALL="C" PATH="[removed]" VSLANG="1033" ZERO_AR_DATE="1" "cc" "-Wl,-exported_symbols_list,/var/folders/p8/qpmzbsdn07g5gxykwfxxw7y40000gn/T/rustci8tkvp/list" "-target" "x86_64-apple-ios13.0-macabi" "/var/folders/p8/qpmzbsdn07g5gxykwfxxw7y40000gn/T/rustci8tkvp/symbols.o" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps/[user].[user].a2ccc648-cgu.0.rcgu.o" "-L" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps" "-L" "/path/to/my/[project]/[user]/target/release/deps" "-L" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/build/blake3-74e6ba91506ce712/out" "-L" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/build/blake3-74e6ba91506ce712/out" "-L" "/Users/[user]/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/x86_64-apple-ios-macabi/lib" "/var/folders/p8/qpmzbsdn07g5gxykwfxxw7y40000gn/T/rustci8tkvp/libblake3-343c1616c8f62c66.rlib" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps/libcompiler_builtins-15d4f20b641cf9ef.rlib" "-framework" "Security" "-framework" "CoreFoundation" "-framework" "Security" "-liconv" "-lSystem" "-lobjc" "-framework" "Security" "-framework" "Foundation" "-lc" "-lm" "-isysroot" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk" "-Wl,-syslibroot" "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk" "-L" "/Users/[user]/.rustup/toolchains/nightly-aarch64-apple-darwin/lib/rustlib/x86_64-apple-ios-macabi/lib" "-o" "/path/to/my/[project]/[user]/target/x86_64-apple-ios-macabi/release/deps/lib[user].dylib" "-Wl,-dead_strip" "-dynamiclib" "-Wl,-dylib" "-nodefaultlibs" = note: clang: error: invalid version number in '-target x86_64-apple-ios13.0-macabi' warning: `[user]` (lib) generated 6 warnings error: could not compile `[user]` due to previous error; 6 warnings emitted ``` </details> ### Minimal example C code: ```c #include <stdio.h> void main() { int a = 1; int b = 2; int c = a + b; printf("%d", c); } ``` `clang` command sample: ``` ➜ 202301 clang -target x86_64-apple-ios13.0-macabi main.c clang: error: invalid version number in '-target x86_64-apple-ios13.0-macabi' ➜ 202301 clang -target x86_64-apple-ios14.0-macabi main.c main.c:2:1: warning: return type of 'main' is not 'int' [-Wmain-return-type] void main() { ^ main.c:2:1: note: change return type to 'int' void main() { ^~~~ int 1 warning generated. ➜ 202301 clang -target x86_64-apple-ios15.0-macabi main.c main.c:2:1: warning: return type of 'main' is not 'int' [-Wmain-return-type] void main() { ^ main.c:2:1: note: change return type to 'int' void main() { ^~~~ int 1 warning generated. ➜ 202301 clang -target x86_64-apple-ios-macabi main.c main.c:2:1: warning: return type of 'main' is not 'int' [-Wmain-return-type] void main() { ^ main.c:2:1: note: change return type to 'int' void main() { ^~~~ int 1 warning generated. ➜ 202301 clang --version Apple clang version 14.0.0 (clang-1400.0.29.202) Target: arm64-apple-darwin22.2.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin ``` This PR is a simplified version of #96392, inspired by https://github.com/rust-lang/cc-rs/pull/727
2023-01-26Remove hardcoded clang target: ios13 or ios14 for Mac Catalyst [fixed]imWildCat-3/+3
2023-01-23Rollup merge of #106796 - vadorovsky:revert-105708-enable-atomic-cas-bpf, ↵Yuki Okushi-1/+1
r=bjorn3 BPF: Disable atomic CAS Enabling CAS for BPF targets (https://github.com/rust-lang/rust/pull/105708) breaks the build of core library. The failure occurs both when building rustc for BPF targets and when building crates for BPF targets with the current nightly. The LLVM BPF backend does not correctly lower all `atomicrmw` operations and crashes for unsupported ones. Before we can enable CAS for BPF in Rust, we need to fix the LLVM BPF backend first. Fixes #106795 Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
2023-01-20Enable sanitizers for s390x-linuxUlrich Weigand-2/+6
Include sanitizers supported by LLVM on s390x (asan, lsan, msan, tsan) in the target definition, as well as in the compiletest supported list. Build sanitizer runtime for the target. Enable sanitizers in the CI.
2023-01-17Remove double spaces after dots in commentsMaybe Waffle-11/+11
2023-01-14BPF: Disable atomic CASMichal Rostecki-1/+1
Enabling CAS for BPF targets (#105708) breaks the build of core library. The failure occurs both when building rustc for BPF targets and when building crates for BPF targets with the current nightly. The LLVM BPF backend does not correctly lower all `atomicrmw` operations and crashes for unsupported ones. Before we can enable CAS for BPF in Rust, we need to fix the LLVM BPF backend first. Fixes #106795 Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
2023-01-11Stabilize `abi_efiapi` featureNicholas Bishop-5/+1
Tracking issue: https://github.com/rust-lang/rust/issues/65815
2023-01-10Rollup merge of #106636 - djkoloski:accept_old_fuchsia_triple, r=tmandryYuki Okushi-1/+7
Accept old spelling of Fuchsia target triples The old spelling of Fuchsia target triples was changed in #106429 to add a proper vendor. Because the old spelling is widely used, some projects may need time to migrate their uses to the new triple spelling. The old spelling may eventually be removed altogether. r? ``@tmandry``
2023-01-10Rollup merge of #105708 - tomerze:enable-atomic-cas-bpf, r=nagisaYuki Okushi-1/+5
Enable atomic cas for bpf targets It seems like LLVM now supports it. https://reviews.llvm.org/D72184 - the PR in LLVM
2023-01-09Add issue number to FIXMEsTyler Mandry-2/+2
2023-01-09Accept old spelling of Fuchsia target triplesDavid Koloski-1/+7
Because the old spelling is widely used, some projects may need time to migrate their uses to the new triple spelling. The old spelling may eventually be removed altogether.
2023-01-06Enable Shadow Call Stack for Fuchsia on AArch64Paul Kirth-1/+3
Fuchsia already uses SCS by default for C/C++ code on ARM hardware. This patch allows SCS to be used for Rust code as well.
2023-01-06Auto merge of #106429 - djkoloski:add_vendor_to_fuchsia_target_triple, r=nagisabors-4/+4
Add vendor to Fuchsia's target triple Historically, Rust's Fuchsia targets have been labeled x86_64-fuchsia and aarch64-fuchsia. However, they should technically contain vendor information. This CL changes Fuchsia's target triples to include the "unknown" vendor since Clang now does normalization and handles all triple spellings. This was previously attempted in #90510, which was closed due to inactivity.
2023-01-05Fix `uninlined_format_args` for some compiler cratesnils-12/+12
Convert all the crates that have had their diagnostic migration completed (except save_analysis because that will be deleted soon and apfloat because of the licensing problem).
2023-01-05Add vendor to Fuchsia's target tripleDavid Koloski-4/+4
Historically, Rust's Fuchsia targets have been labeled x86_64-fuchsia and aarch64-fuchsia. However, they should technically contain vendor information. This CL changes Fuchsia's target triples to include the "unknown" vendor since Clang now does normalization and handles all triple spellings. This was previously attempted in #90510, which was closed due to inactivity.
2023-01-03Auto merge of #105712 - amg98:feat/vita-support, r=wesleywiserbors-0/+42
PlayStation Vita support Just the compiler definitions for no-std projects and std support using newlib Earlier PR: https://github.com/rust-lang/rust/pull/105606
2022-12-25fix some typosKaDiWa-1/+1
2022-12-20rustc: Remove needless lifetimesJeremy Stucki-1/+1
2022-12-15more clippy::complexity fixesMatthias Krüger-7/+2
2022-12-14Added PlayStation Vita supportAndrés Martínez-0/+42
2022-12-14Enable atomic cas for bpf targetsTomer Zeitune-1/+5
2022-12-10compiler: remove unnecessary imports and qualified pathsKaDiWa-2/+0
2022-12-10Rollup merge of #105109 - rcvalle:rust-kcfi, r=bjorn3Matthias Krüger-3/+11
Add LLVM KCFI support to the Rust compiler This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.) Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653). LLVM KCFI can be enabled with -Zsanitizer=kcfi. Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
2022-12-09Rollup merge of #105489 - eltociear:patch-17, r=Dylan-DPCMatthias Krüger-1/+1
Fix typo in apple_base.rs erronous -> erroneous
2022-12-09Rollup merge of #105468 - sunfishcode:sunfishcode/main-void-wasi, r=estebankMatthias Krüger-0/+4
Mangle "main" as "__main_void" on wasm32-wasi On wasm, the age-old C trick of having a main function which can either have no arguments or argc+argv doesn't work, because wasm requires caller and callee signatures to match. WASI's current strategy is to have compilers mangle main's name to indicate which signature they're using. Rust uses the no-argument form, which should be mangled as `__main_void`. This is needed on wasm32-wasi as of #105395.
2022-12-09Fix typo in apple_base.rsIkko Ashimine-1/+1
erronous -> erroneous
2022-12-08Add LLVM KCFI support to the Rust compilerRamon de C Valle-3/+11
This commit adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.) Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653). LLVM KCFI can be enabled with -Zsanitizer=kcfi. Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2022-12-08Mangle "main" as "__main_void" on wasm32-wasiDan Gohman-0/+4
On wasm, the age-old C trick of having a main function which can either have no arguments or argc+argv doesn't work, because wasm requires caller and callee signatures to match. WASI's current strategy is to have compilers mangle main's name to indicate which signature they're using. Rust uses the no-argument form, which should be mangled as `__main_void`. This is needed on wasm32-wasi as of #105395.
2022-12-08Rollup merge of #105405 - sunfishcode:sunfishcode/export-dynamic, r=TaKO8KiMatthias Krüger-7/+0
Stop passing -export-dynamic to wasm-ld. -export-dynamic was a temporary hack added in the early days of the Rust wasm32 target when Rust didn't have a way to specify wasm exports in the source code. This flag causes all global symbols, and some compiler-internal symbols, to be exported, which is often more than needed. Rust now does have a way to specify exports in the source code: `#[export_name = "..."]`. So as the original comment suggests, -export-dynamic can now be removed, allowing users to have smaller binaries and better encapsulation in their wasm32-unknown-unknown modules. It's possible that this change will require existing wasm32-unknown-unknown users will to add explicit `#[export_name = "..."]` directives to exporrt the symbols that their programs depend on having exported.
2022-12-06Stop passing -export-dynamic to wasm-ld.Dan Gohman-7/+0
-export-dynamic was a temporary hack added in the early days of the Rust wasm32 target when Rust didn't have a way to specify wasm exports in the source code. This flag causes all global symbols, and some compiler-internal symbols, to be exported, which is often more than needed. Rust now does have a way to specify exports in the source code: `#[export_name = "..."]`. So as the original comment suggests, -export-dynamic can now be removed, allowing users to have smaller binaries and better encapsulation in their wasm32-unknown-unknown modules. It's possible that this change will require existing wasm32-unknown-unknown users will to add explicit `#[export_name = "..."]` directives to exporrt the symbols that their programs depend on having exported.
2022-12-04Rollup merge of #105123 - BlackHoleFox:fixing-the-macos-deployment, r=oli-obkMatthias Krüger-32/+51
Fix passing MACOSX_DEPLOYMENT_TARGET to the linker I messed up in https://github.com/rust-lang/rust/pull/103929 when merging the two base files together and as a result, started ignoring `MACOSX_DEPLOYMENT_TARGET` at the linker level. This ended up being the cause of nighty builds not running on older macOS versions. My original hope with the previous PR was that CI would have caught something like that but there were only tests checking the compiler target definitions in codegen tests. Because of how badly this sucks to break, I put together a new test via `run-make` that actually confirms the deployment target set makes it to the linker instead of just LLVM. Closes https://github.com/rust-lang/rust/issues/104570 (for real this time)
2022-12-03Rollup merge of #105050 - WaffleLapkin:uselessrefign, r=jyn514Matthias Krüger-1/+1
Remove useless borrows and derefs They are nothing more than noise. <sub>These are not all of them, but my clippy started crashing (stack overflow), so rip :(</sub>
2022-12-02Fix passing MACOSX_DEPLOYMENT_TARGET to the linkerBlackHoleFox-32/+51
2022-12-01Remove useless borrows and derefsMaybe Waffle-1/+1
2022-11-30Extract llvm datalayout parsing out of spec modulehkalbasi-90/+2
2022-11-29Rollup merge of #104523 - flba-eb:fix_nto_target_name, r=wesleywiserMatthias Krüger-2/+2
Don't use periods in target names Using a period in the target name can cause issues in e.g. cargo, see also https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Running.20tests.20on.20remote.20target
2022-11-27Prefer doc comments over `//`-comments in compilerMaybe Waffle-7/+7
2022-11-24move things from rustc_target::abi to rustc_abihkalbasi-1/+118
2022-11-23Rollup merge of #102293 - ecnelises:aix.initial, r=davidtwcoYuki Okushi-0/+63
Add powerpc64-ibm-aix as Tier-3 target This is part of the effort mentioned in https://github.com/rust-lang/compiler-team/issues/553. A reference to these options are definitions from [clang](https://github.com/llvm/llvm-project/blob/ad6fe32032a6229e0c40510e9bed419a01c695b3/clang/lib/Basic/Targets/PPC.h#L414-L448) and [llvm](https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/PowerPC/PPCTargetMachine.cpp). AIX has a system `ld` but [its options and behaviors](https://www.ibm.com/docs/en/aix/7.3?topic=l-ld-command) are different from GNU ld. Thanks to ``@bzEq`` for contributing the linking args.
2022-11-19Rollup merge of #104001 - Ayush1325:custom-entry, r=bjorn3Dylan DPC-0/+27
Improve generating Custom entry function This commit is aimed at making compiler-generated entry functions (Basically just C `main` right now) more generic so other targets can do similar things for custom entry. This was initially implemented as part of https://github.com/rust-lang/rust/pull/100316. Currently, this moves the entry function name and Call convention to the target spec. Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
2022-11-17Auto merge of #104361 - vladimir-ea:watchos_fix_linking, r=oli-obkbors-0/+4
[watchos] Dynamic linking is not allowed for watchos targets Dynamic linking of all apple targets was (re-) enabled in PR #100636. However, dynamic linking is not allowed on WatchOS so this broke the build of standard library for WatchOS. This change disables dynamic linking for WatchOS non-simulator targets.
2022-11-17Remove periods from QNX/nto target namesFlorian Bartels-2/+2
2022-11-17Add powerpc64-ibm-aix as Tier-3 targetQiu Chaofan-0/+63
2022-11-16Rollup merge of #104137 - StackDoubleFlow:err-lsc-unsupported, r=bjorn3Matthias Krüger-5/+5
Issue error when -C link-self-contained option is used on unsupported platforms The documentation was also updated to reflect this. I'm assuming the supported platforms are the same as initially written in [RELEASES.md](https://github.com/rust-lang/rust/blob/master/RELEASES.md#compiler-17). Fixes #103576
2022-11-14Issue error when `-C link-self-contained` option is used on unsupported ↵StackDoubleFlow-5/+5
platforms Document supported targets for `-C link-self-contained` Move `LinkSelfContainedDefault::True` from wasm_base to wasm32_wasi
2022-11-13[watchos] Dynamic linking is not allowed for watchos targetsVladimir Michael Eatwell-0/+4
2022-11-13fix some typos in commentscui fliter-1/+1
Signed-off-by: cui fliter <imcusg@gmail.com>
2022-11-11Add no_std AArch64 support for the QNX Neutrino (nto) 7.1 RTOSFlorian Bartels-0/+72
This change allows to compile no_std applications for the QNX Neutrino realtime operating system for ARM 64 bit CPUs. Tested with QNX Neutrino 7.1.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-01 01:16:22 +0000