From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101825 invoked by alias); 1 May 2015 00:01:09 -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 101814 invoked by uid 89); 1 May 2015 00:01:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 May 2015 00:01:07 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [66.207.208.102]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id 8C558C0A2; Fri, 1 May 2015 00:01:05 +0000 (UTC) Date: Fri, 01 May 2015 00:01:00 -0000 From: Trevor Saunders To: Joseph Myers Cc: Jakub Jelinek , Andreas Schwab , Jeff Law , tbsaunde+gcc@tbsaunde.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS Message-ID: <20150501000058.GD12263@tsaunders-iceball.corp.tor1.mozilla.com> References: <1430114140-15817-4-git-send-email-tbsaunde+gcc@tbsaunde.org> <87oam7nmck.fsf@igel.home> <20150429212811.GA17482@tsaunders-iceball.corp.tor1.mozilla.com> <87383iob0i.fsf@igel.home> <5541548F.40608@redhat.com> <20150429222548.GB17482@tsaunders-iceball.corp.tor1.mozilla.com> <87r3r2i0el.fsf@igel.home> <20150430122513.GB1508@tsaunders-iceball.corp.tor1.mozilla.com> <20150430123344.GQ1751@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-05/txt/msg00000.txt.bz2 On Thu, Apr 30, 2015 at 05:41:57PM +0000, Joseph Myers wrote: > On Thu, 30 Apr 2015, Jakub Jelinek wrote: > > > > I guess the "best" thing to do is justadd a > > > __PCC_BITFIELD_TYPE_MATTERS__ that gcc defines and use that in libobjc? > > > > I think adding way too many predefines, especially rarely used ones, is > > harmful, certainly it isn't free, consider -g3 or -dD where it will all end > > up in, additional gcc start overhead, ... > > That's why we have -fbuilding-libgcc. It would seem reasonable enough to > me to use that when building other target libraries that need such > information. > > (See bug 24775 regarding the general issue with libobjc using GCC's struct > layout target macros - I think there was an idea of a way to rework that > libobjc code, but haven't looked at the details of Andrew Pinski's old > work referred to in that bug; -fbuilding-libgcc may not be the optimal way > of dealing with PCC_BITFIELD_TYPE_MATTERS, but ought to work as an interim I think I saw this and forgot about it and then resaw it just now in documenting this macro tm.texi provides a program that supposedly can check the behavior of the compiler here so writing a autoconf test seems about as simple as it can get when m4 is involved. > fix. More generally, regarding host-side target macros used in target > code, see my suggestions at > . It's always > necessary, when changing the semantics of a target macro or converting it > into a hook, to watch out for uses outside the gcc/ directory, until all > the remaining uses in target code have been dealt with.) if we want to be pedantic this patch didn't actually change semantics, here's what tm.texi says. If the macro is defined, its definition should be a C expression; a nonzero value for the expression enables this behavior. Note that if this macro is not defined, or its value is zero, some bit-fields may cross more than one alignment boundary. The compiler can support such references if there are @samp{insv}, @samp{extv}, and @samp{extzv} insns that can directly reference memory. so, its valid for PCC_BITFIELD_TYPE_MATTERS to be defined to 0 in defaults.h. Of course documentation should never really be trusted that much and its still broken :) Trev > > -- > Joseph S. Myers > joseph@codesourcery.com