From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8A00D3858C2D; Wed, 30 Mar 2022 14:45:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A00D3858C2D 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: Wed, 30 Mar 2022 14:45:31 +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: cc 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: Wed, 30 Mar 2022 14:45:31 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102772 Jakub Jelinek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jason at gcc dot gnu.org, | |redi at gcc dot gnu.org --- Comment #31 from Jakub Jelinek --- Oops, the above commit is an error, there is no placement new and it is abo= ut 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 =3D MAX (TYPE_ALIGN (long_long_integer_type_node), 8644 TYPE_ALIGN (long_double_type_node)); 8645 if (float128_type_node !=3D NULL_TREE) 8646 max_align =3D 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.=