From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DE1273857C41; Mon, 21 Mar 2022 13:17:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DE1273857C41 From: "jakub at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/102772] [12 regression] g++.dg/torture/pr80334.C FAILs Date: Mon, 21 Mar 2022 13:17:50 +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: jakub at gcc dot gnu.org 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: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 13:17:51 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102772 --- Comment #14 from Jakub Jelinek --- 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 sho= uld 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 ou= t 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 th= at decides if the alignment of the var can be done, so perhaps we'd need a tar= get hook that for Solaris would say that one can't increase alignment of TLS va= rs. 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)?=