From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98390 invoked by alias); 2 May 2015 13:26:17 -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 98378 invoked by uid 89); 2 May 2015 13:26:17 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sat, 02 May 2015 13:26:16 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id E02E28E790; Sat, 2 May 2015 13:26:14 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-116-89.ams2.redhat.com [10.36.116.89]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t42DQCle020741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 2 May 2015 09:26:14 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t42DQBg7008762; Sat, 2 May 2015 15:26:11 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t42DQ98D008761; Sat, 2 May 2015 15:26:09 +0200 Date: Sat, 02 May 2015 13:26:00 -0000 From: Jakub Jelinek To: Trevor Saunders Cc: tbsaunde+gcc@tbsaunde.org, gcc-patches@gcc.gnu.org Subject: Re: [PATCH] fixup libobjc usage of PCC_BITFIELD_TYPE_MATTERS Message-ID: <20150502132609.GY1751@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <1430537453-25556-1-git-send-email-tbsaunde+gcc@tbsaunde.org> <20150502080313.GV1751@tucnak.redhat.com> <20150502120846.GA32141@tsaunders-iceball.corp.tor1.mozilla.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150502120846.GA32141@tsaunders-iceball.corp.tor1.mozilla.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00136.txt.bz2 On Sat, May 02, 2015 at 09:08:21AM -0400, Trevor Saunders wrote: > > > + AC_TRY_COMPILE( > > > + [struct foo1 { char x; char :0; char y; }; > > > +struct foo2 { char x; int :0; char y; }; > > > +int foo1test[ sizeof (struct foo1) == 2 ? 1 : -1 ]; > > > +int foo2test[ sizeof (struct foo2) == 5 ? 1 : -1]; ], > > > > Shouldn't the 5 be sizeof (int) + 1? I mean, we have targets with 16-bit > > ints. I hope no target sizeof (int) == 1, that would break this test too > > (perhaps you could use long long :0; instead?). > > yeah, I just mindlessly ported the test program in tm.texi. I'm dubious > anyone tries to use objective C on machines with 16 bit int, and doing > it on a machine with 8 bit int sounds insane, but who knows, and maybe > something else will need this test some day? 8-bit int isn't C compliant, generally, char has to be at least 8-bit, short and int at least 16-bit, long at least 32-bit and long long at least 64-bit (this comes from the C requirements of minimum value for U{CHAR,SHRT,INT,LONG,LLONG}_MAX). sizeof (int) == 1 was for the case where e.g. char would be 16-bit and int as well, or 32-bit char and 32-bit int, etc. Jakub