From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 68B223945C30; Wed, 23 Mar 2022 13:56:19 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 68B223945C30
From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs
Date: Wed, 23 Mar 2022 13:56:18 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: testsuite-fail, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-102772-4-tCpVUuK5Vc@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-102772-4@http.gcc.gnu.org/bugzilla/>
References: <bug-102772-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Mar 2022 13:56:19 -0000

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

--- 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 th=
e 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).=