From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43083 invoked by alias); 30 Apr 2015 02:11:06 -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 43072 invoked by uid 89); 30 Apr 2015 02:11:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.4 required=5.0 tests=AWL,BAYES_40,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; Thu, 30 Apr 2015 02:11:05 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [66.207.208.102]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id 76013C0A2; Thu, 30 Apr 2015 02:11:02 +0000 (UTC) Date: Thu, 30 Apr 2015 03:24:00 -0000 From: Trevor Saunders To: Jeff Law Cc: Andreas Schwab , tbsaunde+gcc@tbsaunde.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH 3/8] add default for PCC_BITFIELD_TYPE_MATTERS Message-ID: <20150430021055.GD17482@tsaunders-iceball.corp.tor1.mozilla.com> References: <1430114140-15817-1-git-send-email-tbsaunde+gcc@tbsaunde.org> <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> <55415B46.5020801@redhat.com> <20150430001316.GC17482@tsaunders-iceball.corp.tor1.mozilla.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150430001316.GC17482@tsaunders-iceball.corp.tor1.mozilla.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-04/txt/msg01954.txt.bz2 On Wed, Apr 29, 2015 at 08:13:16PM -0400, Trevor Saunders wrote: > On Wed, Apr 29, 2015 at 04:29:26PM -0600, Jeff Law wrote: > > On 04/29/2015 04:25 PM, Trevor Saunders wrote: > > >On Wed, Apr 29, 2015 at 04:00:47PM -0600, Jeff Law wrote: > > >>On 04/29/2015 03:55 PM, Andreas Schwab wrote: > > >>>Trevor Saunders writes: > > >>> > > >>>>it passes for me on x86_64-linux after that commit, what platform is > > >>>>this? > > >>> > > >>>Any one with #undef PCC_BITFIELD_TYPE_MATTERS. See libobjc/encoding.c. > > >>Can't you just answer the question Andreas instead of making Trevor go > > >>looking around? You already have this information, why make his job harder? > > > > > > > > >actually pointing out libojc/encoding.c was more useful since that makes > > >it pretty clear the ifndef PCC_BITFIELD_TYPE_MATTERS there just needs to > > >be changed to #if ! > > > > > >>Trevor, try m68k-elf cross. > > > > > >ok, lets see if I can get this to work (its an execution test that > > >breaks, so I'll need to setup binutils and qemu) > > I've actually got a aranym m68k emulator here... So I can do native > > bootstrapping and testing for m68k linux. If you want me to test something, > > just let me know -- FWIW, it takes a week or so to bootstrap ;-) > > Well the fix is just this > > diff --git a/libobjc/encoding.c b/libobjc/encoding.c > index 7333908..20ace46 100644 > --- a/libobjc/encoding.c > +++ b/libobjc/encoding.c > @@ -1167,7 +1167,7 @@ objc_layout_structure_next_member (struct objc_struct_layout *layout) > /* Record must have at least as much alignment as any field. > Otherwise, the alignment of the field within the record > is meaningless. */ > -#ifndef PCC_BITFIELD_TYPE_MATTERS > +#if !PCC_BITFIELD_TYPE_MATTERS > layout->record_align = MAX (layout->record_align, desired_align); > #else /* PCC_BITFIELD_TYPE_MATTERS */ > if (*type == _C_BFLD) > > I looked at the .i built for m68k-linux-elf before and after the > patch and it does what I expect it should do and is a pretty obvious > part that should go with the rest of this patch. > > Obviously something else should be done in the long run at least to > separate gcc and libobjc configuration, but I can't see an argument > for that patch not being ok for now so I'm inclined to check it in > with the current level of testing. I decided to commit this, it seems like testing it can be slow on some targets and I did a bootstrap on x86_64-linux-gnu (with regtest queued) and it seems very very unlikely to break anything else. Trev > > Trev > > > > > jeff