This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils


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 <mmintrin.h>

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]