This is the mail archive of the 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

If sizeof(T)*8 < n, let T' be the largest integral POD type with
sizeof(T')*8 <= n. The bitfield is allocated starting at the next
offset aligned appropriately for T', with length n bits. The first
sizeof(T)*8 bits are used to hold the value of the bitfield,
followed by n - sizeof(T)*8 bits of padding.

T' is long long (what happens when __int128_t type is added btw: will
bitfield alignment suddently change?), so the above text requires the
The ABI doesn't contemplate adding new integral types as you go.  We'll
have to cross that bridge when we get there.

bitfield to be allocated starting at the next offset aligned appropriately
for long long (which is 32-bit alignment), with length 64 bits.

(If the text said at the next offset aligned appropriately for bitfield
with base type T' or something like that, it would be different).
That is what it meant to say.  It does say "The bitfield is
allocated..."; it doesn't transform it into an ordinary field.

I agree that it's not perfectly clear.  Sadly, the ABI committee stopped
working before we had a chance to tear the draft apart and put it back
together with all these issues ironed out.

The real oddity here is that "long long : 64" is aligned more strictly
than "long long" by the C compiler.  There's nothing we can do about
that, but that's why we're confused.  No sane ABI would do that, and the
ABI committee didn't consider insane C ABIs.

The EDG front end has no support for this oddity either, by the way.  I
expect you will find that EDG based compilers put "long long : 64" on a
4-byte aligned location on x86.  It is of course possible for EDG users to
add support for the odd behavior, but it's not in the source code shipped
by EDG.

I have confirmed that Intel behaves different from GCC on:

 struct S {
   char a;
   long long : 64;
   char b;

in C on x86; they give this size 16 instead of 24.

I've notified both Intel and EDG of this incompatibility.

In any case, I don't want to approve a patch for GCC 3.2 to change this
behavior back; I think the new behavior is more correct.  Nathan agreed.

Unless Jason objects strenuously, let's consider this issue closed.

The bottom line is that we don't have a patch.  Unless someone is going
to make one PDQ, what are we going to do?
Well, for IA-32 the fix should be trivial (see bellow). x86-64 will have
to wait for 3.3.
OK, put that one in.  As you say, x86-64 will have to wait.

Mark Mitchell      
CodeSourcery, LLC  

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