[Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs

["ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102772

--- Comment #21 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> If it is the linker, you can always objdump -dr the binary to see what is in
> there after linking. s@ntpoff in my understanding is a relocation that should
> supply at link time the offset from the TLS base and at least on the GCC side
> it can appear anywhere where 32-bit immediate appears in an instruction (or in
> data section too), not necessarily in addl imm, %eax instruction.

The linker isn't a factor here: both ld and gld 2.38 produce the same
result:

08048890 <_Z3foov>:
 8048890:       65 a1 00 00 00 00       mov    %gs:0x0,%eax
 8048896:       05 d0 ff ff ff          add    $0xffffffd0,%eax
 804889b:       c3                      ret    

> Perhaps also try to have 2 different functions, one with
>         movl    %gs:0, %eax
>         addl    $s@ntpoff, %eax
>         ret
> and another with
>         pushl   %ebx
>         movl    %gs:0, %ebx
>         addl    $s@ntpoff, %ebx
>         popl    %ebx
>         ret
> and see what they do at runtime (if they both print the same address in each
> thread or not).

They don't at all: I've also added in the thread id.  I get

        foo      foob

$ ./ta48-ebx
id =  3 fdf80a90 8066638
[...]
id =  1 fe682a90 0
id = 46 fbf66290 8067b0c
[...]
id = 41 fbf63a90 80678a0

All other threads are similarly off: not 16-byte aligned and completely
different from the %eax results.

To verify, I've run the test under dbx (gdb currently lacks TLS support
on Solaris) and print &s in the initial thread: the result matches the
foo value above for id = 1, which suggests they are consistent.