From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14098 invoked by alias); 6 Aug 2002 06:36:51 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 13850 invoked from network); 6 Aug 2002 06:36:48 -0000 Received: from unknown (HELO devserv.devel.redhat.com) (66.187.233.200) by sources.redhat.com with SMTP; 6 Aug 2002 06:36:48 -0000 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.11.6/8.11.0) id g766aZV23694; Tue, 6 Aug 2002 02:36:35 -0400 Date: Mon, 05 Aug 2002 23:36:00 -0000 From: Jakub Jelinek To: Richard Henderson , Mark Mitchell , "Martin v. Loewis" , Richard Henderson , "gcc@gcc.gnu.org" Subject: Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils Message-ID: <20020806023635.I1596@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <4220000.1028584720@warlock.codesourcery.com> <20020805182922.H1596@devserv.devel.redhat.com> <20020805164814.A13920@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020805164814.A13920@redhat.com>; from rth@redhat.com on Mon, Aug 05, 2002 at 04:48:14PM -0700 X-SW-Source: 2002-08/txt/msg00314.txt.bz2 On Mon, Aug 05, 2002 at 04:48:14PM -0700, Richard Henderson wrote: > On Mon, Aug 05, 2002 at 06:29:22PM -0400, Jakub Jelinek wrote: > > > , and what we're doing about Franz's versioning suggestion. > > > > As I already wrote, I don't think this is necessary, especially this late > > in the game, but if Richard or Geoff think otherwise... > > My mail has been screwed up all weekend. What's the issue here? Franz wants to export a bunch of libgcc_s symbols at @@GCC_3.0 and @GLIBC_2.0 instead of current @@GLIBC_2.0. See http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00252.html > > BTW: What about the IA-32 bitfield ABI bug and what about __m64 alignment? > > Is the bitfield thing the alignment of long long bit fields? No, the bitfield is alignment of things like int foo : 128; etc. This changed when Jan removed BIGGEST_FIELD_ALIGNMENT, as in this case the type is SImode and the proposed alignment is 64 and BIGGEST_FIELD_ALIGNMENT was giving 32 while in x86_field_alignment this only happens for {DI,DC,DCI,DF}mode and not SImode as needed in this case. There are a couple of tests for this in Intel ABI testsuite and it is a regression from 3.1. See http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00293.html. > I seem to recall seeing something about C++ changing, but that > it now matched C. Did someone check and see that C changed at > some point in the 3.x series? C doesn't allow oversized bitfields, for say int it treats them as int foo : 32 when they are bigger (at least gcc, haven't checked the standards on this). > As for __m64, IIRC this is fixed on mainline. We should indeed > backport this for 3.2. Thanks for the reminder. Maybe I misunderstood the thread about SSE types in June, but I understood this should succeed, shouldn't it: #include struct A { char a; __m64 b; char c; } x; int foo () { if ((char *) &x.b - &x.a != 8) abort (); if (&x.c - (char *) &x.b != 8) abort (); if (sizeof (x) != 24) abort (); } (unlike long long instead of __m64). This fails on mainline too. Jakub