From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.axis.com (smtp1.axis.com [195.60.68.17]) by sourceware.org (Postfix) with ESMTPS id 914B83858D35 for ; Thu, 20 Jan 2022 04:51:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 914B83858D35 From: Hans-Peter Nilsson To: Jason Merrill CC: In-Reply-To: <20211217032655.711331-1-jason@redhat.com> (message from Jason Merrill via Gcc-patches on Fri, 17 Dec 2021 04:26:55 +0100) Subject: Re: [pushed] c++: layout of aggregate base with DMI [PR103681] MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT References: <20211217032655.711331-1-jason@redhat.com> Message-ID: <20220120045147.B15E120415@pchp3.se.axis.com> Date: Thu, 20 Jan 2022 05:51:47 +0100 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2022 04:51:51 -0000 > From: Jason Merrill via Gcc-patches > Date: Fri, 17 Dec 2021 04:26:55 +0100 > C++14 changed the definition of 'aggregate' to allow default member > initializers, but such classes still need to be considered "non-POD for the > purpose of layout" for ABI compatibility with C++11 code. It seems rare to > derive from such a class, as evidenced by how long this bug has > survived (since r216750 in 2014), but it's certainly worth fixing. > > We only warn when we were failing to allocate another field into the > tail padding of the newly aggregate class; this is the only ABI impact. > > This also changes end_of_class to consider all data members, not just empty > data members; that used to be an additional flag, removed in r9-5710, but I > don't see any reason not to always include them. This makes the result of > the function correspond to the ABI nvsize term and its nameless counterpart > that does include virtual bases. > > When looking closely at other users of end_of_class, I realized that we were > assuming that the latter corresponded to the ABI dsize term, but it doesn't > if the class ends with an empty virtual base (in the rare case that the > empty base can't be assigned offset 0), and this matters for layout of > [[no_unique_address]]. So I added another mode that returns the desired > value for that case. I'm not adding a warning for this ABI fix because it's > a C++20 feature. > > Tested x86_64-pc-linux-gnu, applying to trunk. > > PR c++/103681 > > gcc/ChangeLog: > > * common.opt (fabi-version): Add v17. > > gcc/cp/ChangeLog: > > * cp-tree.h (struct lang_type): Add non_pod_aggregate. > (CLASSTYPE_NON_POD_AGGREGATE): New. > * class.c (check_field_decls): Set it. > (check_bases_and_members): Check it. > (check_non_pod_aggregate): New. > (enum eoc_mode): New. > (end_of_class): Always include non-empty fields. > Add eoc_nv_or_dsize mode. > (include_empty_classes, layout_class_type): Adjust. Looks like this caused https://gcc.gnu.org/PR104139. brgds, H-P