about summary refs log tree commit diff
path: root/tests/codegen
AgeCommit message (Collapse)AuthorLines
2024-10-14Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assemblyTaiki Endo-0/+36
2024-10-11Rollup merge of #131310 - taiki-e:msp430-clobber-abi, r=AmanieuTrevor Gross-0/+36
Support clobber_abi in MSP430 inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335. Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf) cc ``@cr1901`` r? ``@Amanieu`` ``@rustbot`` label +O-msp430
2024-10-11Rollup merge of #131519 - davidlattimore:intrinsics-default-vis, r=UrgauMatthias Krüger-0/+16
Use Default visibility for rustc-generated C symbol declarations Non-default visibilities should only be used for definitions, not declarations, otherwise linking can fail. This is based on https://github.com/rust-lang/rust/pull/123994. Issue https://github.com/rust-lang/rust/issues/123427 When I changed `default-hidden-visibility` to `default-visibility` in https://github.com/rust-lang/rust/pull/130005, I updated all places in the code that used `default-hidden-visibility`, replicating the hidden-visibility bug to also happen for protected visibility. Without this change, trying to build rustc with `-Z default-visibility=protected` fails with a link error.
2024-10-11compiletest: Remove the magic hacks for finding output with `lto=thin`Zalathar-6/+0
This hack was intended to handle the case where `-Clto=thin` causes the compiler to emit multiple output files (when producing LLVM-IR or assembly). The hack only affects 4 tests, of which 3 are just meta-tests for the hack itself. The one remaining test that motivated the hack currently doesn't even need it! (`tests/codegen/issues/issue-81408-dllimport-thinlto-windows.rs`)
2024-10-11Use Default visibility for rustc-generated C symbol declarationsDavid Lattimore-0/+16
Non-default visibilities should only be used for definitions, not declarations, otherwise linking can fail. Co-authored-by: Collin Baker <collinbaker@chromium.org>
2024-10-08Auto merge of #131387 - Zalathar:rollup-kprp512, r=Zalatharbors-0/+6
Rollup of 7 pull requests Successful merges: - #130824 (Add missing module flags for `-Zfunction-return=thunk-extern`) - #131170 (Fix `target_vendor` in non-IDF Xtensa ESP32 targets) - #131355 (Add tests for some old fixed issues) - #131369 (Update books) - #131370 (rustdoc: improve `<wbr>`-insertion for SCREAMING_CAMEL_CASE) - #131379 (Fix utf8-bom test) - #131385 (Un-vacation myself) r? `@ghost` `@rustbot` modify labels: rollup
2024-10-08Rollup merge of #130824 - Darksonn:fix-function-return, r=wesleywiserStuart Cook-0/+6
Add missing module flags for `-Zfunction-return=thunk-extern` This fixes a bug in the `-Zfunction-return=thunk-extern` flag. The flag needs to be passed onto LLVM to ensure that functions such as `asan.module_ctor` and `asan.module_dtor` that are created internally in LLVM have the mitigation applied to them. This was originally discovered [in the Linux kernel](https://lore.kernel.org/all/CANiq72myZL4_poCMuNFevtpYYc0V0embjSuKb7y=C+m3vVA_8g@mail.gmail.com/). Original flag PR: #116892 PR for similar issue: #129373 Tracking issue: #116853 cc ``@ojeda`` r? ``@wesleywiser``
2024-10-07Add precondition checks to ptr::offset, ptr::add, ptr::subBen Kimock-2/+6
2024-10-06various fixes for `naked_asm!` implementationFolkert de Vries-1/+1
- fix for divergence - fix error message - fix another cranelift test - fix some cranelift things - don't set the NORETURN option for naked asm - fix use of naked_asm! in doc comment - fix use of naked_asm! in run-make test - use `span_bug` in unreachable branch
2024-10-06more `asm!` -> `naked_asm!` in testsFolkert de Vries-2/+1
2024-10-06disallow `asm!` in `#[naked]` functionsFolkert de Vries-8/+8
also disallow the `noreturn` option, and infer `naked_asm!` as `!`
2024-10-06use `naked_asm!` in naked-function testsFolkert-3/+3
2024-10-06Support clobber_abi in MSP430 inline assemblyTaiki Endo-0/+36
2024-10-03Avoid emptiness check in `PeekMut::pop`EFanZh-0/+13
2024-10-01Auto merge of #131111 - matthiaskrgr:rollup-n6do187, r=matthiaskrgrbors-8/+10
Rollup of 4 pull requests Successful merges: - #130005 (Replace -Z default-hidden-visibility with -Z default-visibility) - #130229 (ptr::add/sub: do not claim equivalence with `offset(c as isize)`) - #130773 (Update Unicode escapes in `/library/core/src/char/methods.rs`) - #130933 (rustdoc: lists items that contain multiple paragraphs are more clear) r? `@ghost` `@rustbot` modify labels: rollup
2024-10-01Rollup merge of #130630 - taiki-e:s390x-clobber-abi, r=AmanieuGuillaume Gomez-0/+50
Support clobber_abi and vector/access registers (clobber-only) in s390x inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335. This also supports vector registers (as `vreg`) and access registers (as `areg`) as clobber-only, which need to support clobbering of them to implement clobber_abi. Refs: - "1.2.1.1. Register Preservation Rules" section in ELF Application Binary Interface s390x Supplement, Version 1.6.1 (lzsabi_s390x.pdf in https://github.com/IBM/s390x-abi/releases/tag/v1.6.1) - Register definition in LLVM: - Vector registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L249 - Access registers https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L332 I have three questions: - ~~ELF Application Binary Interface s390x Supplement says that `cc` (condition code, bits 18-19 of PSW) is "Volatile". However, we do not have a register class for `cc` and instead mark `cc` as clobbered unless `preserves_flags` is specified (https://github.com/rust-lang/rust/pull/111331). Therefore, in the current implementation, if both `preserves_flags` and `clobber_abi` are specified, `cc` is not marked as clobbered. Is this okay? Or even if `preserves_flags` is used, should `cc` be marked as clobbered if `clobber_abi` is used?~~ UPDATE: resolved https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121 - ~~ELF Application Binary Interface s390x Supplement says that `pm` (program mask, bits 20-23 of PSW) is "Cleared". There does not appear to be any registers associated with this in either [LLVM](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td) or [GCC](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L407-L431), so at this point I don't see any way other than to just ignore it. Is this okay as-is?~~ UPDATE: resolved https://github.com/rust-lang/rust/pull/130630#issuecomment-2367923121 - Is "areg" a good name for register class name for access registers? It may be a bit confusing between that and `reg_addr`, which uses the “a” constraint (https://github.com/rust-lang/rust/pull/119431)... Note: - GCC seems to [recognize only `a0` and `a1`](https://github.com/gcc-mirror/gcc/blob/33ccc1314dcdb0b988a9276ca6b6ce9b07bea21e/gcc/config/s390/s390.h#L428-L429), and using `a[2-15]` [causes errors](https://godbolt.org/z/a46vx8jjn). Given that cg_gcc has a similar problem with other architecture (https://github.com/rust-lang/rustc_codegen_gcc/issues/485), I don't feel this is a blocker for this PR, but it is worth mentioning here. - `vreg` should be able to accept `#[repr(simd)]` types as input if the `vector` target feature added in https://github.com/rust-lang/rust/pull/127506 is enabled, but core_arch has no s390x vector type and both `#[repr(simd)]` and `core::simd` are unstable, so I have not implemented it in this PR. EDIT: And supporting it is probably more complex than doing the equivalent on other architectures... https://github.com/rust-lang/rust/pull/88245#issuecomment-905559591 cc `@uweigand` r? `@Amanieu` `@rustbot` label +O-SystemZ
2024-10-01Replace -Z default-hidden-visibility with -Z default-visibilityDavid Lattimore-8/+10
MCP: https://github.com/rust-lang/compiler-team/issues/782 Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2024-09-25Add missing module flags for function-return=thunk-externAlice Ryhl-0/+6
2024-09-23Improve autovectorization of to_lowercase / to_uppercase functionsJörn Horstmann-0/+23
Refactor the code in the `convert_while_ascii` helper function to make it more suitable for auto-vectorization and also process the full ascii prefix of the string. The generic case conversion logic will only be invoked starting from the first non-ascii character. The runtime on microbenchmarks with ascii-only inputs improves between 1.5x for short and 4x for long inputs on x86_64 and aarch64. The new implementation also encapsulates all unsafe inside the `convert_while_ascii` function. Fixes #123712
2024-09-22tests: Remove spuriously failing vec-tryinto-array codegen testJubilee Young-22/+0
2024-09-21Auto merge of #129283 - saethlin:unreachable-allocas, r=scottmcmbors-8/+33
Don't alloca for unused locals We already have a concept of mono-unreachable basic blocks; this is primarily useful for ensuring that we do not compile code under an `if false`. But since we never gave locals the same analysis, a large local only used under an `if false` will still have stack space allocated for it. There are 3 places we traverse MIR during monomorphization: Inside the collector, `non_ssa_locals`, and the walk to generate code. Unfortunately, https://github.com/rust-lang/rust/pull/129283#issuecomment-2297925578 indicates that we cannot afford the expense of tracking reachable locals during the collector's traversal, so we do need at least two mono-reachable traversals. And of course caching is of no help here because the benchmarks that regress are incr-unchanged; they don't do any codegen. This fixes the second problem in https://github.com/rust-lang/rust/issues/129282, and brings us anther step toward `const if` at home.
2024-09-21Compute reachable locals as part of non_ssa_localsBen Kimock-10/+14
2024-09-21Don't alloca for unused localsBen Kimock-3/+24
2024-09-20Rollup merge of #128209 - beetrees:no-macos-10.10, r=jieyouxuGuillaume Gomez-27/+0
Remove macOS 10.10 dynamic linker bug workaround Rust's current minimum macOS version is 10.12, so the hack can be removed. This PR also updates the `remove_dir_all` docs to reflect that all supported macOS versions are protected against TOCTOU race conditions (the fallback implementation was already removed in #127683). try-job: dist-x86_64-apple try-job: dist-aarch64-apple try-job: dist-apple-various try-job: aarch64-apple try-job: x86_64-apple-1
2024-09-21Support clobber_abi and vector/access registers (clobber-only) in s390x ↵Taiki Endo-0/+50
inline assembly
2024-09-18Rollup merge of #130487 - cuviper:min-llvm-18, r=nikicJubilee-9/+0
Update the minimum external LLVM to 18 With this change, we'll have stable support for LLVM 18 and 19. For reference, the previous increase to LLVM 17 was #122649. cc `@rust-lang/wg-llvm` r? nikic
2024-09-18Update the minimum external LLVM to 18Josh Stone-9/+0
2024-09-18tests: Move wasm32 to transparent-opaque-ptr.rs testJubilee Young-4/+4
2024-09-18tests: Remove test for wrong wasm codegenJubilee Young-26/+2
2024-09-18Rollup merge of #130466 - davidtwco:aarch64-transparent-test, r=jieyouxuMatthias Krüger-3/+116
tests: add repr/transparent test for aarch64 Fixes #74396. Moves `transparent-struct-ptr.rs` to `transparent-byval-struct-ptr.rs` and then adds a new `transparent-opaque-ptr.rs` for aarch64.
2024-09-17tests: allow trunc/select instructions to be missingAugie Fackler-5/+8
On LLVM 20, these instructions already get eliminated, which at least partially satisfies a TODO. I'm not talented enough at using FileCheck to try and constrain this further, but if we really want to we could copy an LLVM 20 specific version of this test that would restore it to being CHECK-NEXT: insertvalue ... @rustbot label: +llvm-main
2024-09-17tests: add repr/transparent test for aarch64David Wood-3/+116
Moves `transparent-struct-ptr.rs` to `transparent-byval-struct-ptr.rs` and then adds a new `transparent-opaque-ptr.rs` for aarch64.
2024-09-14Update try_question_mark_nop.rs testDianQK-1/+6
2024-09-14Simplify the canonical clone method to copyDianQK-2/+44
The optimized clone method ends up as the following MIR: ``` _2 = copy ((*_1).0: i32); _3 = copy ((*_1).1: u64); _4 = copy ((*_1).2: [i8; 3]); _0 = Foo { a: move _2, b: move _3, c: move _4 }; ``` We can transform this to: ``` _0 = copy (*_1); ```
2024-09-10Auto merge of #129403 - scottmcm:only-array-simd, r=compiler-errorsbors-343/+180
Ban non-array SIMD Nearing the end of https://github.com/rust-lang/compiler-team/issues/621 ! Currently blocked on ~~https://github.com/rust-lang/compiler-builtins/pull/673~~ ~~https://github.com/rust-lang/compiler-builtins/pull/674~~ ~~https://github.com/rust-lang/rust/pull/129400~~ ~~https://github.com/rust-lang/rust/pull/129481~~ for windows.
2024-09-09Ban non-array SIMDScott McMurray-343/+180
2024-09-09adapt a test for llvm 20Krasimir Georgiev-0/+1
No functional changes intended.
2024-09-07Rollup merge of #129891 - nikic:naked-no-san, r=jackh726Michael Goulet-0/+22
Do not request sanitizers for naked functions Naked functions can only contain inline asm, so any instrumentation inserted by sanitizers is illegal. Don't request it. Fixes https://github.com/rust-lang/rust/issues/129224.
2024-09-06Do not request sanitizers for naked functionsNikita Popov-0/+22
Naked functions can only contain inline asm, so any instrumentation inserted by sanitizers is illegal. Don't request it. Fixes https://github.com/rust-lang/rust/issues/129224.
2024-09-06Auto merge of #121614 - clubby789:no-expect, r=saethlinbors-1/+1
Don't emit `expect`/`assume` in opt-level=0 LLVM does not make use of expect/assume calls in `opt-level=0`, so we can simplify IR by not emitting them in this case.
2024-09-04Remove macOS 10.10 dynamic linker bug workaroundbeetrees-27/+0
2024-09-04Don't codegen `expect` in opt-level=0clubby789-1/+1
2024-08-31ignore/fix layout-sensitive testsThe 8472-0/+4
2024-08-29Rollup merge of #129316 - dingxiangfei2009:riscv64-imac-scs, r=nnethercoteGuillaume Gomez-0/+17
riscv64imac: allow shadow call stack sanitizer cc `@Darksonn` for shadow call stack sanitizer support on RV64IMAC and RV64GC
2024-08-29Rollup merge of #128970 - DianQK:lint-llvm-ir, r=nikicGuillaume Gomez-3/+4
Add `-Zlint-llvm-ir` This flag is similar to `-Zverify-llvm-ir` and allows us to lint the generated IR. r? compiler
2024-08-29riscv64imac: allow shadow call stack sanitizerDing Xiang Fei-0/+17
2024-08-29Add `-Zlint-llvm-ir`DianQK-3/+4
2024-08-28Rollup merge of #128192 - mrkajetanp:feature-detect, r=AmanieuJubilee-7/+7
rustc_target: Add various aarch64 features Add various aarch64 features already supported by LLVM and Linux. Additionally include some comment fixes to ensure consistency of feature names with the Arm ARM. Compiler support for features added to stdarch by https://github.com/rust-lang/stdarch/pull/1614. Tracking issue for unstable aarch64 features is https://github.com/rust-lang/rust/issues/127764. List of added features: - FEAT_CSSC - FEAT_ECV - FEAT_FAMINMAX - FEAT_FLAGM2 - FEAT_FP8 - FEAT_FP8DOT2 - FEAT_FP8DOT4 - FEAT_FP8FMA - FEAT_HBC - FEAT_LSE128 - FEAT_LSE2 - FEAT_LUT - FEAT_MOPS - FEAT_LRCPC3 - FEAT_SVE_B16B16 - FEAT_SVE2p1 - FEAT_WFxT - FEAT_SME - FEAT_SME_F16F16 - FEAT_SME_F64F64 - FEAT_SME_F8F16 - FEAT_SME_F8F32 - FEAT_SME_FA64 - FEAT_SME_I16I64 - FEAT_SME_LUTv2 - FEAT_SME2 - FEAT_SME2p1 - FEAT_SSVE_FP8DOT2 - FEAT_SSVE_FP8DOT4 - FEAT_SSVE_FP8FMA FEAT_FPMR is added in the first commit and then removed in a separate one to highlight it being removed from upstream LLVM 19. The intention is for it to be detectable at runtime through stdarch but not have a corresponding Rust compile-time feature.
2024-08-28Rollup merge of #129421 - jdonszelmann:naked-repr-align-functions, ↵Matthias Krüger-0/+20
r=workingjubilee,compiler-errors add repr to the allowlist for naked functions Fixes #129412 (combining unstable features #90957 (`#![feature(naked_functions)]`) and #82232 (`#![feature(fn_align)]`)
2024-08-27add repr to the allowlist for naked functions, and test that it worksjdonszelmann-0/+20
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-14 06:15:46 +0000