[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 #18 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #16)
>> I've wrapped that in a small test programming, calling foo both from the
>> initial thread and a new one: in all cases, the return value from foo
>> was 32-byte aligned as expected.
>
> Perhaps the problem only shows when the PT_TLS size is not a multiple of the
> alignment?  Or depends on other PT_TLS segments in shared libraries in the same
> process.  The pointer2.f90 testcase will link against libgomp which uses TLS as
> well.
> So perhaps try:
> struct __attribute__((aligned (16))) S { char buf[0x24]; };
> __thread struct S s;
> __attribute__((noipa)) S *foo (void) { return &s; }
> int
> main ()
> {
>   #pragma omp parallel
>   __builtin_printf ("%p\n", foo ());
>   return 0;
> }
> ?

I've compiled that with g++ -m32 -O2 -fopenmp.  Initially, when foo was
just

        movl    %gs:0, %eax
        addl    $s@ntpoff, %eax
        ret

this worked reliably, emitting a 16-byte aligned address 48 times
(matching the number of cores).

However, when I changed the assembler output to

        pushl   %ebx
        movl    %gs:0, %ebx
        addl    $s@ntpoff, %ebx
        popl    %ebx
        ret

and relinked, the resulting addresses were just 4-byte aligned, exactly
one of them even being 0.

That might again suggest the Solaris ld/ld.so.1 took the TLS spec
literally (provided I've not created that mess myself: IIUC, %ebx is
callee-saved).