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

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

[ro at gcc dot gnu.org]

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

            Bug ID: 102772
           Summary: [12 regression] g++.dg/torture/pr80334.C FAILs
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: hjl at gcc dot gnu.org
  Target Milestone: ---
              Host: *86*-pc-solaris2.11
            Target: *86*-pc-solaris2.11
             Build: *86*-pc-solaris2.11

Between 20210802 (38fb24ba4d67254cea78731fc8d961903dad9646) and 20210804
(929f2cf4105ccf12d0684c6d5838f58f0ee5e7c7),
g++.dg/torture/pr80334.C began to FAIL on 32-bit Solaris/x86:

FAIL: g++.dg/torture/pr80334.C   -O0  execution test
FAIL: g++.dg/torture/pr80334.C   -O1  execution test
FAIL: g++.dg/torture/pr80334.C   -O2  execution test
FAIL: g++.dg/torture/pr80334.C   -O2 -flto  execution test
FAIL: g++.dg/torture/pr80334.C   -O2 -flto -flto-partition=none  execution test
FAIL: g++.dg/torture/pr80334.C   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: g++.dg/torture/pr80334.C   -O3 -g  execution test
FAIL: g++.dg/torture/pr80334.C   -Os  execution test

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x08050d7b in main () at
/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/torture/pr80334.C:15
15            auto a = new A(b[i].unpacked);
(gdb) where
#0  0x08050d7b in main () at
/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/torture/pr80334.C:15

=> 0x8050d7b <main()+110>:      movaps %xmm7,(%edx)

(gdb) p/x $edx
$1 = 0x8065a98

I'm attaching the gcc 11.1.0 and master assembler output for comparison.

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

[ro at gcc dot gnu.org]

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

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 51607
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51607&action=edit
master assembler output

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

[ro at gcc dot gnu.org]

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

--- Comment #2 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 51608
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51608&action=edit
gcc-11 assembler output

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

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-10-15

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
The stack isn't properly realigned.  Please find out which commit caused this.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
           Priority|P3                          |P1

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
> The stack isn't properly realigned.  Please find out which commit caused this.

Sure: a reghunt identified

commit 29f0e955c97da002b5adb4e8c9dfd2ea9709e207
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Mon Aug 2 10:01:46 2021 -0700

    x86: Update piecewise move and store

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

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
         Depends on|                            |36159, 56726

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
It is similar to PR 36159.  Alignment of the return of new operator
is wrong.  It happens to work on Linux where new returns a pointer
to a memory block which is 16-byte aligned.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36159
[Bug 36159] C++ compiler should issue a warning with missing new operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56726
[Bug 56726] i386: MALLOC_ABI_ALIGNMENT is too small (usually)

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As I wrote in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80334#c2 , I believe
the testcase is just invalid.

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

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> ---
There's another instance of the same problem:

libgomp.fortran/pointer2.f90 FAILs at -O2 and above:

FAIL: libgomp.fortran/pointer2.f90   -O2  execution test
FAIL: libgomp.fortran/pointer2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
FAIL: libgomp.fortran/pointer2.f90   -O3 -g  execution test

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
Segmentation Fault

Thread 9 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2 (LWP 2)]
0x080517ba in MAIN__::MAIN__._omp_fn.0 () at
/vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.fortran/pointer2.f90:14
14      !$omp parallel copyin (thr) reduction(.or.:l) reduction(+:i)
1: x/i $pc
=> 0x80517ba <MAIN__::MAIN__._omp_fn.0+42>:     movaps %xmm7,-0x28(%ebx)
(gdb) where
#0  0x080517ba in MAIN__::MAIN__._omp_fn.0 () at
/vol/gcc/src/hg/master/local/libgomp/testsuite/libgomp.fortran/pointer2.f90:14
#1  0xfe2d40dc in gomp_thread_start (xdata=<optimized out>) at
/vol/gcc/src/hg/master/local/libgomp/team.c:129
#2  0xfdfd327b in _thrp_setup () from /lib/libc.so.1
#3  0xfdfd35b0 in ?? () from /lib/libc.so.1
#4  0x00000000 in ?? ()
(gdb) p/x $ebx
$1 = 0xfe1202c0
(gdb) p/x $ebx-0x28
$2 = 0xfe120298

so this is another unaligned access, it seems.

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

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Does libgomp.fortran/pointer2.f90 still FAIL?

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Does libgomp.fortran/pointer2.f90 still FAIL?

It does.

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

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Is this with Solaris as or GNU as?
I've tried to reproduce it with a cross from x86_64-linux to
i386-pc-solaris2.11 and have
#define HAVE_AS_TLS 1
in auto-host.h, but I don't see any movaps instructions in pointer2.f90 with
-O2 -fopenmp or -O3 -fopenmp.
When I add -msse2 to command line, I see some but it is unclear which exact is
it.
So, can you please attach pointer2.s and say on which exact insn it fails?
And also attach your auto-host.h?
Thanks.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Is this with Solaris as or GNU as?

both.

> I've tried to reproduce it with a cross from x86_64-linux to
> i386-pc-solaris2.11 and have
> #define HAVE_AS_TLS 1
> in auto-host.h, but I don't see any movaps instructions in pointer2.f90 with
> -O2 -fopenmp or -O3 -fopenmp.

I do, both at -O2 and -O3:

pointer2.s:     movaps  %xmm1, thr.1@ntpoff(%ebx)
pointer2.s:     movaps  %xmm2, thr.1@ntpoff+16(%ebx)

> When I add -msse2 to command line, I see some but it is unclear which exact is
> it.
> So, can you please attach pointer2.s and say on which exact insn it fails?

Will do.

Thread 49 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 2 (LWP 2)]
0x0805181a in MAIN__._omp_fn.0 ()
1: x/i $pc
=> 0x805181a <MAIN__._omp_fn.0+42>:     movaps %xmm1,-0x28(%ebx)
(gdb) x/10i $pc-10
   0x8051810 <MAIN__._omp_fn.0+32>:     shlb   $0x46,-0x75(%ebx,%eiz,1)
   0x8051815 <MAIN__._omp_fn.0+37>:     adc    %dh,%bl
   0x8051817 <MAIN__._omp_fn.0+39>:     movq   (%eax),%mm1
=> 0x805181a <MAIN__._omp_fn.0+42>:     movaps %xmm1,-0x28(%ebx)
   0x8051821 <MAIN__._omp_fn.0+49>:     movdqu 0x10(%eax),%xmm2
   0x8051826 <MAIN__._omp_fn.0+54>:     movaps %xmm2,-0x18(%ebx)
(gdb) p/x $ebx
$1 = 0xfe1202c0

> And also attach your auto-host.h?

Sure: I'm attaching the gas one.  The only obviously tls-related
differences between the two are

--- master/11.4-gcc/build/gcc/auto-host.h       2022-03-20 21:20:00.738284645
+0
000
+++ master/11.4-gcc-gas/build/gcc/auto-host.h   2022-03-21 03:06:50.783523035
+0
000
[...]
@@ -538 +538 @@
-#define HAVE_AS_IX86_TLSGDPLT 1
+/* #undef HAVE_AS_IX86_TLSGDPLT */
@@ -550 +550 @@
-#define HAVE_AS_IX86_TLSLDMPLT 1
+#define HAVE_AS_IX86_TLSLDMPLT 0

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

[ro at gcc dot gnu.org]

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

--- Comment #12 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 52654
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52654&action=edit
32-bit i386-pc-solaris2.11 pointer2.s with -O2

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

[ro at gcc dot gnu.org]

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

--- Comment #13 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 52655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52655&action=edit
i386-pc-solaris2.11 auto-host.h with gas

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

[jakub at gcc dot gnu.org]

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

--- 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
What about the executable (in that case the PT_TLS segment is more important
(whether it has 16-byte p_align).
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.
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)?

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

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There is a general question if we shouldn't give up in can_increase_alignment_p
for all DECL_THREAD_LOCAL_P vars because increasing their alignment doesn't
mean just a few wasted bytes per process due to the alignment, but a few wasted
bytes per thread (TLS space is or should be far more space constrained than
normal data or rodata sections).
But even if we do that, the question is if alignas(16) thread_local vars etc.
work on Solaris.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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.

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

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #16)
> Same here:
> 
> Program Headers:
>   Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
> [...]
>   TLS            0x00c3d0 0x0806c3d0 0x00000000 0x00000 0x00024 RW  0x10

If both linkers reproduce the problem and the PT_TLS is 16-byte aligned
and thr.1 in it is at offset 0 (or multiple of 16), then I'd think that points
to the dynamic linker.
The TLS transitions are performed by the linker.

> > 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.

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;
}
?

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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).

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

[jakub at gcc dot gnu.org]

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

--- 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.
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).

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

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note, for ntpoff the listed instructions are:
movl %gs:0,%eax
leal x@ntpoff(%eax),%eax
rather than addl.  But certainly this one was never meant to be taken
pedantically as that instruction sequence only, it is completely intentional
that the %gs:0 load can be far away (used by multiple TLS LE or IE accesses),
and
even tls.pdf mentions some other instructions:
movl %gs:0,%eax
movl x@ntpoff(%eax),%eax
and
movl %gs:x@ntpoff,%eax
are all mentioned.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #22 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #20 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Note, for ntpoff the listed instructions are:
> movl %gs:0,%eax
> leal x@ntpoff(%eax),%eax
> rather than addl.  But certainly this one was never meant to be taken
> pedantically as that instruction sequence only, it is completely intentional
> that the %gs:0 load can be far away (used by multiple TLS LE or IE accesses),
> and
> even tls.pdf mentions some other instructions:
> movl %gs:0,%eax
> movl x@ntpoff(%eax),%eax
> and
> movl %gs:x@ntpoff,%eax
> are all mentioned.

In the Solaris Linkers and Libraries Guide I'd mentioned, those forms
are all listed.  However, this wouldn't be the first case where the
registers in the spec were taken literally on Solaris: see i386.cc
(legitimize_tls_address) <TLS_MODEL_INITIAL_EXEC> and i386.md
(tls_initial_exec_64_sun) where Solaris only accepts %rax.

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

[jakub at gcc dot gnu.org]

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

--- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #21)
> > --- 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    

How does foob look like when linked (from both)?

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #23 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #21)
>> 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    
>
> How does foob look like when linked (from both)?

For ld:

08050f40 <_Z4foobv>:
 8050f40:       53                      push   %ebx
 8050f41:       65 8b 1d 00 00 00 00    mov    %gs:0x0,%ebx
 8050f48:       81 c3 d0 ff ff ff       add    $0xffffffd0,%ebx
 8050f4e:       5b                      pop    %ebx
 8050f4f:       c3                      ret    

Completely identical between ld and gld, except for the exact address of
_Z4foobv itself due to different segment layout:

For gld:

080488a0 <_Z4foobv>:
 80488a0:       53                      push   %ebx
 80488a1:       65 8b 1d 00 00 00 00    mov    %gs:0x0,%ebx
 80488a8:       81 c3 d0 ff ff ff       add    $0xffffffd0,%ebx
 80488ae:       5b                      pop    %ebx
 80488af:       c3                      ret

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

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, sorry, my fault apparently.
        pushl   %ebx
        movl    %gs:0, %ebx
        addl    $s@ntpoff, %ebx
        popl    %ebx
        ret
of course doesn't make sense, because when it is a function, it should return
the value in %eax, while the above computes something into %ebx and overwrites
it and then just returns an uninitialized reg.
So we need:
        pushl   %ebx
        movl    %gs:0, %ebx
        addl    $s@ntpoff, %ebx
        movl    %ebx, %eax
        popl    %ebx
        ret

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #26 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Ah, sorry, my fault apparently.
>         pushl   %ebx
>         movl    %gs:0, %ebx
>         addl    $s@ntpoff, %ebx
>         popl    %ebx
>         ret

I messed this up myself: didn't thing apparently ;-)

> of course doesn't make sense, because when it is a function, it should return
> the value in %eax, while the above computes something into %ebx and overwrites
> it and then just returns an uninitialized reg.
> So we need:
>         pushl   %ebx
>         movl    %gs:0, %ebx
>         addl    $s@ntpoff, %ebx
>         movl    %ebx, %eax
>         popl    %ebx
>         ret

With that change, foo () and foob () always return the same result.

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

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But then we are back at figuring out what exactly is wrong with the
libgomp.fortran/pointer2.f90 testcase.
Can you perhaps upload the failing binary and corresponding *.o file?

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

[ro at gcc dot gnu.org]

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

--- Comment #28 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 52688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52688&action=edit
32-bit i386-pc-solaris2.11 pointer2.{exe,o,s}

pointer2.f90 executable etc. as of 29f0e955c97da002b5adb4e8c9dfd2ea9709e207.

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

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, that looks like a linker bug:
        movaps  %xmm7, thr.1@ntpoff(%ebx)
...
        movaps  %xmm7, thr.1@ntpoff+16(%ebx)
...
        movl    %eax, thr.1@ntpoff+32(%ebx)
in assembly correctly turned into:
  2a:   0f 29 bb 00 00 00 00    movaps %xmm7,0x0(%ebx)
                        2d: R_386_TLS_LE        thr.1
...
  36:   0f 29 bb 10 00 00 00    movaps %xmm7,0x10(%ebx)
                        39: R_386_TLS_LE        thr.1
...
  40:   89 83 20 00 00 00       mov    %eax,0x20(%ebx)
                        42: R_386_TLS_LE        thr.1
  [ 5] .tbss             NOBITS          00000000 000570 000024 00 WAT  0   0
16
But linker turns that into:
 80517ba:       0f 29 bb d8 ff ff ff    movaps %xmm7,-0x28(%ebx)
...
 80517c6:       0f 29 bb e8 ff ff ff    movaps %xmm7,-0x18(%ebx)
...
 80517d0:       89 83 f8 ff ff ff       mov    %eax,-0x8(%ebx)
Even when dynamic linker properly ensures the %gs:0 base is 16-byte aligned
because PT_TLS segment is:
  TLS            0x00b6f0 0x0806b6f0 0x00000000 0x00000 0x00024 RW  0x10
the R_386_TLS_LE immediates are off, they don't take into account the needed
alignment.

We should probably use a better small testcase:
struct S { char buf[0x24]; };
__thread struct S s __attribute__((aligned (16)));
__attribute__((noipa)) struct S *foo (void) { return &s; }
int
main ()
{
  #pragma omp parallel
  __builtin_printf ("%p\n", foo ());
  return 0;
}
because with the aligned (16) attribute on struct S we've increased its size to
0x30 that way.

https://akkadia.org/drepper/tls.pdf
says that
tsoffset_1 = round(tlssize_1, align_1)
tlsoffset_m+1 = round(tlsoffset_m + tlssize_m+1, align_m+1)
and as tlssize_1 (of the binary) is 36 and align_1 is 16, tlsoffset_1 is 48
and so R_386_TLS_LE thr.1 should resolve to -48 + 0 (thr.1 is at offset 0 of
the segment).
But it seems the linker instead uses -40, i.e. just the size rounded up to 8
byte alignment boundary rather than 16.

We could work around it on GCC side by padding up any TLS vars up to their
alignment, but that would be horribly expensive, potentially wasting a lot of
the precious TLS memory.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #30 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:6a777ceb0e975f0efc823d2d82e676346f068151

commit r12-7920-g6a777ceb0e975f0efc823d2d82e676346f068151
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Mar 30 16:04:52 2022 +0200

    testsuite: Change pr80334.C testcase to dg-do compile [PR102772]

    The testcase has UB at runtime, placement new shouldn't construct
    an object with certain alignment requirements into an unaligned buffer.

    2022-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/80334
            PR target/102772
            * g++.dg/torture/pr80334.C: Change from dg-do run to dg-do compile.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |redi at gcc dot gnu.org

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Oops, the above commit is an error, there is no placement new and it is about
the alignment returned by operator new.
        movdqu  (%eax), %xmm7
        movaps  %xmm7, (%edx)
where %edx is the value returned by _Znwj.
Now, in C++14 the testcase might be invalid if it operator new doesn't
guarantee 16-byte alignment.
But shouldn't C++17 and later call _ZnwjSt11align_val_t instead of _Znwj if the
latter doesn't guarantee 16-byte alignment?
The threshold above which _ZnwjSt11align_val_t is used is computed by
malloc_alignment:
return MAX (max_align_t_align(), MALLOC_ABI_ALIGNMENT);
and max_align_t_align() is
8643      unsigned int max_align = MAX (TYPE_ALIGN
(long_long_integer_type_node),
8644                                    TYPE_ALIGN (long_double_type_node));
8645      if (float128_type_node != NULL_TREE)
8646        max_align = MAX (max_align, TYPE_ALIGN (float128_type_node));
8647      return max_align;
TYPE_ALIGN of the 3 types are 64-bit, 32-bit and 128-bit for 32-bit Solaris.

So, if 32-bit Solaris doesn't guarantee 128-bit alignment from malloc, I'm
afraid it needs to somehow override this so that max_align_t_align() is only
64-bit.
Or perhaps avoid supporting float128_type_node.
Or in libsupc++ ensure 16-byte alignment from operator new by using
posix_memalign etc.

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

[redi at gcc dot gnu.org]

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

--- Comment #32 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, this is a well known problem that stddef.h's max_align_t does not agree
with malloc on i386 Solaris. Glibc used to have the same problem.

Fixing it in the compiler or in operator new seems reasonable. I'll try doing
the latter.

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

[redi at gcc dot gnu.org]

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

--- Comment #33 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(IMHO we should never have added float128 to max_align_t for targets where we
can't change malloc, but that was decided long ago).

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

[redi at gcc dot gnu.org]

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

--- Comment #34 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Assuming that posix_memalign is slower than malloc (which seems likely), it
would be better to fix this in the compiler by defining
__STDCPP_DEFAULT_NEW_ALIGNMENT__=8 for i386 solaris, instead of setting it to
alignof(max_align_t). That matches what malloc actualy guarantees on the
target.

That would mean that new int[4] can still use malloc, because the compiler
knows the alignment here is 4 and it can just use _Znwj. But for new __float128
it would use _ZnwjSt11align_val_t to get 16-byte alignment that isn't
guaranteed by malloc.

Fixing it in _Znwj inside libsupc++ means that we have to use posix_memalign
for all allocations >= 16 bytes, as we can't tell whether operator new(16) was
called for something that actually needs 16-byte alignment, or for something
like  int[4] or short[8].

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=77691

--- Comment #35 from Jonathan Wakely <redi at gcc dot gnu.org> ---
That said, this would probably fix it:

--- a/libstdc++-v3/libsupc++/new_op.cc
+++ b/libstdc++-v3/libsupc++/new_op.cc
@@ -41,6 +41,11 @@ extern "C" void *malloc (std::size_t);
 _GLIBCXX_WEAK_DEFINITION void *
 operator new (std::size_t sz) _GLIBCXX_THROW (std::bad_alloc)
 {
+#if defined __sun && defined __i386__
+  if (sz >= 16)
+    return ::operator new(sz, std::align_val_t(16));
+#endif
+
   void *p;

   /* malloc (0) is unpredictable; avoid it.  */



As noted in PR 77691, there are other targets where GCC's max_align_t does not
match the target malloc. That includes vxworks and mingw*.

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

[jakub at gcc dot gnu.org]

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

--- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52719
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52719&action=edit
gcc12-pr102772.patch

So like this?

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #37 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #36 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 52719
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52719&action=edit
> gcc12-pr102772.patch
>
> So like this?

Mostly.  There were some issues, though:

* Initially, the patch caused the bootstrap to fail:

In file included from
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/i386-pc-solaris2.11/bits/c++allocator.h:33,
                 from
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/allocator.h:46,
                 from
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/memory:64,
                 from
/vol/gcc/src/hg/master/local/libstdc++-v3/src/c++98/allocator-inst.cc:29:
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:
In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const
void*)':
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:130:24:
error: expected primary-expression before ')' token
  130 |         if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
      |                        ^
      |             ^~~~~~~
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:130:13:
note: (if you use '-fpermissive', G++ will accept your code, but allowing the
use of an undeclared name is deprecated)
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:132:54:
error: there are no arguments to 'alignof' that depend on a template parameter,
so a declaration of 'alignof' must be available [-fpermissive]
  132 |             std::align_val_t __al = std::align_val_t(alignof(_Tp));
      |                                                      ^~~~~~~
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:132:53:
error: expected primary-expression before '(' token
  132 |             std::align_val_t __al = std::align_val_t(alignof(_Tp));
      |                                                     ^
/var/gcc/regression/master/11.4-gcc/build/i386-pc-solaris2.11/libstdc++-v3/include/bits/new_allocator.h:132:65:
error: expected primary-expression before ')' token
  132 |             std::align_val_t __al = std::align_val_t(alignof(_Tp));
      |                                                                 ^

  and several more, affecting

  include/ext/bitmap_allocator.h
  include/ext/mt_allocator.h
  include/ext/pool_allocator.h

  AFAICS, alignof is C++ >= 11 only.  I've used the attached patch to
  use __alignof__ instead, although I don't know if that's the best fix.

* With that, the build completed and g++.dg/torture/pr80334.C PASSes.

  And yes, my tree did include

changeset:   259338:c7f332059508
bookmark:    trunk
tag:         qparent
user:        Jakub Jelinek <jakub@redhat.com>
date:        Wed Mar 30 16:47:10 2022 +0200
summary:     Revert "testsuite: Change pr80334.C testcase to dg-do compile
[PR102772]"

* However, there were quite a number of 32-bit regressions:

+FAIL: g++.dg/cpp1z/aligned-new4.C    (test for warnings, line 11)
+FAIL: g++.dg/cpp1z/aligned-new4a.C    (test for warnings, line 11)
+FAIL: g++.dg/diagnostic/recur-align.C  -std=gnu++14  (test for warnings, line
13)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings, line 132)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings, line 136)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings, line 140)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings, line 155)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings, line 180)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings, line 210)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings, line 233)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings,
 line 241)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings, line 41)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14  (test for
warnings, line 43)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14 (test for excess
errors)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14 note (test for
warnings, line 178)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14 note (test for
warnings, line 208)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14 note (test for
warnings, line 231)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++14 note (test for
warnings, line 238)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 132)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 136)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 140)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 155)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 180)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 210)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 233)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 241)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 41)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98  (test for
warnings, line 43)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98 (test for excess
errors)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98 note (test for
warnings, line 178)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98 note (test for
warnings, line 208)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98 note (test for
warnings, line 231)
+FAIL: g++.dg/warn/Wmismatched-new-delete-2.C  -std=gnu++98 note (test for
warnings, line 238)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14  (test for
warnings, line 108)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14  (test for
warnings, line 110)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14  (test for
warnings, line 116)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14  (test for
warnings, line 122)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14  (test for
warnings, line 128)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14  (test for
warnings, line 138)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14  (test for
warnings, line 144)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14  (test for
warnings, line 150)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14  (test for
warnings, line 156)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++14 (test for excess
errors)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98  (test for
warnings, line 108)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98  (test for
warnings, line 110)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98  (test for
warnings, line 116)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98  (test for
warnings, line 122)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98  (test for
warnings, line 128)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98  (test for
warnings, line 138)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98  (test for
warnings, line 144)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98  (test for
warnings, line 150)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98  (test for
warnings, line 156)
+FAIL: g++.dg/warn/Wmismatched-new-delete-6.C  -std=gnu++98 (test for excess
errors)
+FAIL: g++.dg/warn/Wmismatched-new-delete-7.C  -std=gnu++14 (test for excess
errors)
+FAIL: g++.dg/warn/Wmismatched-new-delete-7.C  -std=gnu++98 (test for excess
errors)

  I don't really understand what's going on here.

  There were two more

+FAIL: 17_intro/headers/c++1998/all_attributes.cc (test for excess errors)

Excess errors:
/var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/ext/malloc_allocator.h:138:
error: expected primary-expression before ')' token
/var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/ext/malloc_allocator.h:138:
error: there are no arguments to 'alignof' that depend on a template parameter,
so a declaration of 'alignof' must be available [-fpermissive]

+FAIL: 17_intro/headers/c++1998/profile_mode.cc (test for excess errors)

Excess errors:
/var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/ext/malloc_allocator.h:138:
error: expected primary-expression before ')' token
/var/gcc/regression/master/11.4-gcc-gas/build/i386-pc-solaris2.11/libstdc++-v3/include/ext/malloc_allocator.h:138:
error: there are no arguments to 'alignof' that depend on a template parameter,
so a declaration of 'alignof' must be available [-fpermissive]

  Those are other instances of alignof not being present in C++98, so I
  changed include/ext/malloc_allocator.h to also use __alignof__ instead
  of alignof, which makes those tests PASS.

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

[ro at gcc dot gnu.org]

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

--- Comment #38 from Rainer Orth <ro at gcc dot gnu.org> ---
Created attachment 52726
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52726&action=edit
Use __alignof__ in several allocator headers.

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

[redi at gcc dot gnu.org]

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

--- Comment #39 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #37)
>   AFAICS, alignof is C++ >= 11 only.  I've used the attached patch to
>   use __alignof__ instead, although I don't know if that's the best fix.

Yes, alignof is C++11 only, but the reason it's OK to use there is that
__STDCPP_DEFAULT_NEW_ALIGNMENT__ is C++17 only, and alignof is guarded by:

#if __cpp_aligned_new
        if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)

Strictly speaking, this code is enabled when -faligned-new is active, which is
true for C++17 by default.

It appears that Jakub's patch makes -faligned-new always active for Solaris
x86, which we don't want.

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

[redi at gcc dot gnu.org]

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

--- Comment #40 from Jonathan Wakely <redi at gcc dot gnu.org> ---
N.B. I don't think we want to replace alignof with __alignof__ because they're
not identical. For x86 alignof(long long) != __alignof__(long long).

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

[jakub at gcc dot gnu.org]

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

--- Comment #41 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #39)
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #37)
> >   AFAICS, alignof is C++ >= 11 only.  I've used the attached patch to
> >   use __alignof__ instead, although I don't know if that's the best fix.
> 
> Yes, alignof is C++11 only, but the reason it's OK to use there is that
> __STDCPP_DEFAULT_NEW_ALIGNMENT__ is C++17 only, and alignof is guarded by:
> 
> #if __cpp_aligned_new
>         if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__)
> 
> Strictly speaking, this code is enabled when -faligned-new is active, which
> is true for C++17 by default.
> 
> It appears that Jakub's patch makes -faligned-new always active for Solaris
> x86, which we don't want.

Ah, indeed, I thought the threshold is separate from it being enabled, but it
is not.
So, we want to change it in the option override handling only if cxx_dialect >=
cxx17, but that is something only defined in c-family, while the backend option
overriding is in code linked with all FEs.
Thus, we'd need to override it instead somewhere in i386-c.cc.
But nothing in that file is called early enough, from what I can see, the
sequence of initialization is:
cxx_dialect set to the default (cxx17 now)
possibly cxx_dialect changed if -std= used on command line
SUBTARGET_OVERRIDE_OPTIONS invoked
cxx_init_decl_processing
4645      if (aligned_new_threshold == -1)
4646        aligned_new_threshold = (cxx_dialect >= cxx17) ? 1 : 0;
4647      if (aligned_new_threshold == 1)
4648        aligned_new_threshold = malloc_alignment () / BITS_PER_UNIT;
code invoked
ix86_register_pragmas from i386-c.cc called
ix86_target_macros from i386-c.cc called

Also, the -Waligned-new= warning uses malloc_alignment () rather than
aligned_new_threshold, so if we want to override something for 32-bit x86
solaris, mingw and vxworks, we probably need something to hook into
malloc_alignment rather than to tweak aligned_new_threshold.

I think we need a target macro for it though rather than target hook, because
it needs to be invoked from the C++ FE and implemented in config/*-c.cc

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

[redi at gcc dot gnu.org]

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

--- Comment #42 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It should really depend on -faligned-new which can be set for C++14 and C++11
too (and I guess C++98 in theory, but that would break when you include <new>
because you can't have 'enum class align_val_t' in C++98). So cxx_dialect isn't
right.

Does -faligned-new get processed already before the hook? If so, can you just
check if the threadshold is already non-zero and change if so? If it's zero,
leave it as zero.

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

[jakub at gcc dot gnu.org]

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

--- Comment #43 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 52727
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52727&action=edit
gcc12-pr102772.patch

Another patch.  This one changes (for now on 32-bit x86 solaris only)
malloc_alignment () value, which is used in 2 places, to initialize
aligned_new_threshold value if user used -falignment-new or -falignment-new=1
or -std=c++17 or later and -falignment-new=SOMETHING_BIGGER_THAN_ONE wasn't
used,
and for -Waligned-new= warning (we warn when non-align_t operator new is used
on types that need bigger alignment than malloc_alignment ()).

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

[jakub at gcc dot gnu.org]

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

--- Comment #44 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Rainer, for pr80334.C, have you been able to test the #c43 patch?
As for TLS and alignment, to confirm it is a ld bug, can you try #c29 testcase
with all of gas + gld, gas + sunld and sunas + sunld (or perhaps just the first
and last from these)?  If gas + gld works and sunas + sunld don't, it would
confirm the sun ld bug.

Thanks.

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

[jakub at gcc dot gnu.org]

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

--- Comment #45 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'd like to ping the #c44 question.  Thanks.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #46 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #44 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Rainer, for pr80334.C, have you been able to test the #c43 patch?

I did: the test FAILs (SEGV) at -m32 -O0 only, same as for unmodified
trunk.

> As for TLS and alignment, to confirm it is a ld bug, can you try #c29 testcase
> with all of gas + gld, gas + sunld and sunas + sunld (or perhaps just the first
> and last from these)?  If gas + gld works and sunas + sunld don't, it would
> confirm the sun ld bug.

I get the same behaviour in all three cases: foo () returns an 8-byte
aligned address.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #45 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> I'd like to ping the #c44 question.  Thanks.

Sorry for the delay: I haven't been well lately.

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

[jakub at gcc dot gnu.org]

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

--- Comment #48 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #47)
> Sorry for the delay: I haven't been well lately.

I'm sorry to hear that.

Anyway, I'm out of ideas and unfortunately Solaris/x86 is not on GCCFarm.

Why is this a P1 when Solaris/x86 is neither primary nor secondary though?
Unless it reproduces also on Solaris/SPARC, which is primary but is on GCCFarm.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #49 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> Anyway, I'm out of ideas and unfortunately Solaris/x86 is not on GCCFarm.

I'd meant to provide a Solaris/x86 system for the cfarm, but it turned
out every user would have to sign an acceptable use policy and run
through a video ident before being granted access, which I consider
unusable for developers and too much effort on the admin side.

I'll see if I can find a different solution, though.

In the meantime, it's possible for indivudual gcc developers to get
regular access to my internal gcc test farm.  I've done that with iant,
for example.  Let me know if you're interested.

> Why is this a P1 when Solaris/x86 is neither primary nor secondary though?

I have no idea: it certainly wasn't me...

> Unless it reproduces also on Solaris/SPARC, which is primary but is on GCCFarm.

No, Solaris/SPARC is fine.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.0                        |12.2

--- Comment #50 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 12.1 is being released, retargeting bugs to GCC 12.2.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|12.3                        |12.4

--- Comment #52 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 12.3 is being released, retargeting bugs to GCC 12.4.