Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

☔ The latest upstream changes (presumably #140415) made this pull request unmergeable. Please resolve the merge conflicts.

@rustbot author

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

☔ The latest upstream changes (presumably #141668) made this pull request unmergeable. Please resolve the merge conflicts.

@bors r+ rollup

📌 Commit 8da54fc has been approved by compiler-errors

It is now in the queue for this repository.

@bors rollup-

⌛ Testing commit 8da54fc with merge 8e7515b...

The job dist-i586-gnu-i586-i686-musl failed! Check out the build log: (web) (plain enhanced) (plain)

---- [ui] tests/ui/asm/const-refs-to-static.rs stdout ----
error: test compilation failed although it shouldn't!
status: exit status: 1
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" "/checkout/tests/ui/asm/const-refs-to-static.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/checkout/vendor" "--sysroot" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage2" "--target=i586-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "--out-dir" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/ui/asm/const-refs-to-static" "-A" "unused" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/checkout/obj/build/i586-unknown-linux-gnu/native/rust-test-helpers" "-Clinker=i586-unknown-linux-gnu-gcc"
stdout: none
--- stderr -------------------------------
error: invalid operand for inline asm constraint 'i'
##[error] --> /checkout/tests/ui/asm/const-refs-to-static.rs:17:20
 |
LL | unsafe { asm!("/* {} */", const addr_of!(FOO)) };
 | ^^^^^^^^
error: aborting due to 1 previous error
------------------------------------------

💔 Test failed - checks-actions

Looks like the i constraint doesn't work for GOT-rebased relocation, which x86 use for PIE and we enable PIE by default. We need to either:

• Say this works only with static relocation-model on x86, or
• Generate symbol + offset ourselves, like global_asm implementation.

Oh, it failed bors but was not marked
@bors r-

☔ The latest upstream changes (presumably #144249) made this pull request unmergeable. Please resolve the merge conflicts.

Looks like the i constraint doesn't work for GOT-rebased relocation

I've been playing around with this a bit, and I think the i operand works as long as using the symbol name would work. For example, this breaks:

#include <stdio.h>
static const int FORTY_TWO = 42;
int main(void) {
 const int *a;
 __asm__ (
 "movabs %1, %0"
 : "=r" (a)
	: "i" (&FORTY_TWO)
 );
 printf("%p\n", (void *)a);
 return 0;
}

/usr/bin/ld: /tmp/ccptrDbi.o: warning: relocation in read-only section `.text'
/usr/bin/ld: warning: creating DT_TEXTREL in a PIE

But when we make it rip-relative, it works:

#include <stdio.h>
static const int FORTY_TWO = 42;
int main(void) {
 const int *a;
 __asm__ (
 "movabs %1 - ., %0"
 : "=r" (a)
	: "i" (&FORTY_TWO)
 );
 printf("%p\n", (void *)a);
 return 0;
}

0xec3

We can even force it to generate a GOT-entry with the address of FORTY_TWO and then look up the value through it:

#include <stdio.h>
static const int FORTY_TWO = 42;
int main(void) {
 const int **a;
 __asm__ (
 "leaq (%c1)@GOTPCREL(%%rip), %0"
 : "=r" (a)
	: "i" (&FORTY_TWO)
 );
 printf("%i\n", **a);
 return 0;
}

42

This is exactly the same scenario as when writing FORTY_TWO would work as far as I can tell. Is there something I'm missing?

It works in x64 but not in x86.

EDIT: Looks like it works in GCC for not Clang/LLVM: https://godbolt.org/z/YodbxxMeY

Ah, that's what I get for testing it with gcc.