From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id AAB8F385840D for ; Mon, 13 Dec 2021 10:35:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AAB8F385840D Received: by mail-wm1-x330.google.com with SMTP id c6-20020a05600c0ac600b0033c3aedd30aso11245378wmr.5 for ; Mon, 13 Dec 2021 02:35:09 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v4cmf7/Nd5kMstmoW+Mg0g+7H37WMlE7eJ3oK/bZWt8=; b=UYQkoMF/9Vh4aK5VHS+FgyqWj83NzbDkQ2ox0uFebEmKJgss+MqjkBVHv5TBNomQpu VBffXoUe3Qp9KSqOJHIOpaO59wpcOLMq0O2dnCMvLY1LRpHkMqnhawB99U+ER9xv0hZj A5Gz9R+O1lNzGouYleSSkZj7vKwLwMHTwhq81Y37BZ4iAYnCqZsBwe9DRTfds4LbWivE 1FmVpBhVWODu0vFIUFWbEIPEF3ivA7/k5Hm7KU4IEMnadY5HcQWPHofttKNoz7ie9H7t xDsmlXqfurODX2cVW17e0whGpnxQqXFIrS9zzPxuK9+Nybr5FGjCEq7uRhkiBJheMX/A yqrA== X-Gm-Message-State: AOAM533zYijHO6JXOcVQZAVXlMh/xrZGFygs1Blcob3aQ2V2k2b/6XeT vcaGO1sAkw4rASKLwwWaLPIQr8zHYbkSKh9DLso= X-Google-Smtp-Source: ABdhPJzZ77nkeTuXiOLVfzH+Mp0mEbWAxT/lNa3XdoO0AiWCOD03jeS0TdRsVSMy+ZN7DYAGo9ClfC7UqqCTlC9Amiw= X-Received: by 2002:a7b:c256:: with SMTP id b22mr36320159wmj.176.1639391708549; Mon, 13 Dec 2021 02:35:08 -0800 (PST) MIME-Version: 1.0 References: <20211213050246epcms1p5b2dfcc034540c005f114473a8f94d94e@epcms1p5> In-Reply-To: From: Jonathan Wakely Date: Mon, 13 Dec 2021 10:34:57 +0000 Message-ID: Subject: Re: Query regarding unusual behaviour for tail padding with different c++ standards To: Andrew Pinski Cc: n.deshmukh@samsung.com, "gcc@gcc.gnu.org" , Sung-Taek Lim , Yash Sharma Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 10:35:11 -0000 On Mon, 13 Dec 2021 at 05:14, Andrew Pinski wrote: > > On Sun, Dec 12, 2021 at 9:04 PM Nayan Deshmukh via Gcc wrote: > > #include > > #include > > #include > > struct A { > > int a; > > uint64_t b; > > int c = -1; > > }; > > The question becomes is the above a standard layout class or not. I > Noticed clang does not change the rules for layout between C++11 and > C++14 but GCC does. > I don't know the exact rules in the ABI to help you there but I do > think you should file a bug because it definitely looks unexpected > really. The C++14 behaviour started with https://gcc.gnu.org/r216750 Implement N3653 (Member initializers and aggregates) and fix references to 'this' in constexpr cons tructors. Implement N3653 (Member initializers and aggregates) and fix references to 'this' in constexpr constructors. * class.c (check_field_decls): In C++14 an NSDMI does not make the class non-aggregate. But I think the layout should be using "POD for the purpose of layout", which means the C++98 POD rules. Please do report it to bugzilla.