Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils

[Jakub Jelinek <jakub at redhat dot com>]

On Tue, Aug 06, 2002 at 09:14:33AM -0700, Mark Mitchell wrote:
> No, there is something wrong with that patch.
> 
> In particular, the test case wants this structure:
> 
> +struct A
> +{
> +  char a;
> +  int b : 224;	// { dg-warning "exceeds its type" "" }
> +  char c;
> +} a, a4[4];
> +
> 
> to have size 36.  That is incorrect.
> 
>   int b: 224;
> 
> should be treated exactly like:
> 
>   long long: 64;
> 
> followed by 160 bits (20 bytes) of padding.
> 
> In the C ABI, a 64-bit long long bit field gets aligned at an 8-byte
> boundary.  So, b goes at offset 8.  We then get 28 bytes for the
> bitfield.  That puts c at offset 36.  The structure is 8-byte aligned,
> for a total size of 40.
> 
> Jakub, what is the bug that you are trying to fix?
> 
> The fact that something changed in 3.1 doesn't prove that it's a bug. :-)

The change for bitfields in 3.1.1 was definitely not intentional (Jan's patch
was about SSE field alignment and TFmode long doubles) and Intel compiler
behaves the same way as gcc always used to.

I looked into C++ standard and couldn't find anything about
int :64; needing exactly the same treatment as long long :64.

> > Hum.  The patch I remember doesn't seem to have been written. :-(
> > As discussed on the thread, __m64 needs to be a vector type so
> > that the x86-64 calling conventions put it in the right set of
> > registers.  Which means a large repetitious patch to mmintrin.h.
> 
> Well, I'm not too concerned about x86-64 just yet.  There still isn't
> any hardware out there.  I can't see holding the release for this.

Not x86-64, but it makes a difference on i686 too (ie. whether __m64
fields in structures are 64-bit or just 32-bit aligned).

	Jakub