From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2C7683858C54; Thu, 31 Mar 2022 14:49:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C7683858C54 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: Thu, 31 Mar 2022 14:49:08 +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: Thu, 31 Mar 2022 14:49:09 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102772 --- Comment #41 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #39) > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #37) > > AFAICS, alignof is C++ >=3D 11 only. I've used the attached patch to > > use __alignof__ instead, although I don't know if that's the best fix. >=20 > 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: >=20 > #if __cpp_aligned_new > if (alignof(_Tp) > __STDCPP_DEFAULT_NEW_ALIGNMENT__) >=20 > Strictly speaking, this code is enabled when -faligned-new is active, whi= ch > is true for C++17 by default. >=20 > It appears that Jakub's patch makes -faligned-new always active for Solar= is > 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_dialec= t >=3D cxx17, but that is something only defined in c-family, while the backend op= tion 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=3D used on command line SUBTARGET_OVERRIDE_OPTIONS invoked cxx_init_decl_processing 4645 if (aligned_new_threshold =3D=3D -1) 4646 aligned_new_threshold =3D (cxx_dialect >=3D cxx17) ? 1 : 0; 4647 if (aligned_new_threshold =3D=3D 1) 4648 aligned_new_threshold =3D 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=3D 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, becau= se it needs to be invoked from the C++ FE and implemented in config/*-c.cc=