From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 83160 invoked by alias); 26 Jan 2016 20:44:21 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 82461 invoked by uid 89); 26 Jan 2016 20:44:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=Hx-languages-length:1833, yyy, H*M:8312, xxx X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 26 Jan 2016 20:44:11 +0000 Received: from 81-64-195-101.rev.numericable.fr (HELO laptop-mg.local) ([81.64.195.101]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jan 2016 21:44:08 +0100 Date: Tue, 26 Jan 2016 20:44:00 -0000 From: Marc Glisse Reply-To: gcc-patches@gcc.gnu.org To: "H.J. Lu" cc: GCC Patches , Jason Merrill , Jakub Jelinek , Richard Biener , Markus Trippelsdorf Subject: Re: PING^1: [PATCH] Add TYPE_EMPTY_RECORD for C++ empty class In-Reply-To: Message-ID: References: <20151209213118.GC317@x4> <566C346B.8030601@redhat.com> <20151212152731.GB18720@tucnak.redhat.com> <566F23AE.6070604@redhat.com> <566F2A0B.4010102@redhat.com> <56A7C8AC.8070204@redhat.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2016-01/txt/msg02036.txt.bz2 On Tue, 26 Jan 2016, H.J. Lu wrote: > On Tue, Jan 26, 2016 at 12:23 PM, Marc Glisse wrote: >> On Tue, 26 Jan 2016, H.J. Lu wrote: >> >>> On Tue, Jan 26, 2016 at 11:27 AM, Jason Merrill wrote: >>>> >>>> On 12/14/2015 05:08 PM, H.J. Lu wrote: >>>>> >>>>> >>>>> + if (abi_version_at_least (10)) >>>>> + TYPE_EMPTY_RECORD (t) = is_really_empty_class (t); >>>> >>>> >>>> >>>> This should use is_empty_class or CLASSTYPE_EMPTY_P. We don't want to >>>> change how classes with just a vptr are passed. >>>> >>>> Otherwise, it looks OK to me. >>> >>> >>> Is true_type an empty class here? is_empty_class returns false >>> on this: >> >> >> It isn't empty in the usual C++ sense (we can't apply the empty base >> optimization to something that derives from it, for instance), or the one >> described in the itanium ABI (the relevant one here I guess). On the other >> hand, it is rather useless to pass it by value, so a different notion of > > llvm/clang treats it as empty class and I think it should be treated > as "empty" class. Is it still empty if there are several empty members? Is there a clear definition somewhere of what empty means? I guess it makes sense to recursively allow "empty" members for this purpose. >> empty might have been useful when the ABI was defined... > > I proposed to update x86-64 psABI: > > https://groups.google.com/forum/#!topic/x86-64-abi/VTE-LJ9VnDk Does the full document have a definition of empty anywhere? >>> [hjl@gnu-skl-1 gcc]$ cat x.cc >>> struct dummy { }; >>> struct true_type { struct dummy i; }; >>> >>> extern true_type y; >>> extern void xxx (true_type c); >>> >>> void >>> yyy (void) >>> { >>> xxx (y); >>> } >>> [hjl@gnu-skl-1 gcc]$ >> >> >> -- >> Marc Glisse -- Marc Glisse