[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 #16 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> If the movaps that it fails on are:
>         movaps  %xmm1, thr.1@ntpoff(%ebx)
>         movdqu  16(%eax), %xmm2
>         movaps  %xmm2, thr.1@ntpoff+16(%ebx)
> then I'd say it must be some Solaris bug, because:
>         .section        .tbss,"awT",@nobits
>         .align 16
>         .type   thr.1, @object
>         .size   thr.1, 36
> thr.1:
>         .zero   36
> so thr.1 symbol should be 16-byte aligned and so movaps to that address should
> work.
> On pointer2.o, is the .tbss section properly 16-byte aligned?
> On i686-linux I see in readelf -Wa:
>   [ 8] .tbss             NOBITS          00000000 000360 000024 00 WAT  0   0
> 16

Same on Solaris:

  [ 8] .tbss             NOBITS          00000000 000330 000024 00 WAT  0   0
16

> What about the executable (in that case the PT_TLS segment is more important
> (whether it has 16-byte p_align).

Same here:

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
[...]
  TLS            0x00c3d0 0x0806c3d0 0x00000000 0x00000 0x00024 RW  0x10

> If Solaris dynamic linker doesn't ensure proper alignment of TLS vars (or
> assembler or linker screw it up in the middle), it would be nice to find out if
> it does for all alignments or just say higher than 8-byte, and perhaps add some
> workaround on the GCC side somewhere.
> On the pointer2.f90 testcase it is symtab_node::can_increase_alignment_p that
> decides if the alignment of the var can be done, so perhaps we'd need a target
> hook that for Solaris would say that one can't increase alignment of TLS vars.

We could try that once we know for certain that's the case (and get it
fixed at the same time).

However, when gld is in use, the test fails in exactly the same way.

> But the question is if in
> struct __attribute__((aligned (32))) S { long long buf[4]; };
> __thread struct S s;
> S *foo (void) { return &s; }
> it won't return not properly 32-byte aligned pointer too (and is that in all
> threads or just some (initial vs. other threads)?

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.

One thing I wondered about: Solaris ld used to be very picky about
exactly following the use of registers in TLS sequences: the Linker and
Libraries guide documents %eax for TLS LE:

https://docs.oracle.com/cd/E37838_01/html/E36783/man-tlsam.html#scrolltoc

Maybe the use of %ebx in this code is the program?  At least the test
program above does use %eax, as expected.

We had issues like this both for amd64 and sparc in the past.