This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Richard Henderson <rth at redhat dot com>, "Martin v. Loewis" <martin at v dot loewis dot de>, Richard Henderson <rth at twiddle dot net>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Tue, 6 Aug 2002 13:56:08 -0400
- Subject: Re: libgcc_s, Linux, and PT_GNU_EH_FRAME, and binutils
- References: <20020806124509.Q1596@devserv.devel.redhat.com> <27820000.1028653434@warlock.codesourcery.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Aug 06, 2002 at 10:03:54AM -0700, Mark Mitchell wrote:
>
> > I looked into C++ standard and couldn't find anything about
> > int :64; needing exactly the same treatment as long long :64.
>
> See:
>
> http://www.codesourcery.com/cxx-abi/abi.html#class-types
>
> In particular, 2.4.II.1.b.
That doesn't make it any more clear than it used to, though
my understanding of this is that gcc 3.0-3.1 were correct in here:
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
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).
The fact that long long foo : 64 bitfields are aligned to 64 bits comes from
the 2.4.II.1.a requirement to match C psABI for bitfields.
> >> > 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).
>
> This is a C ABI issue in addition to being a C++ ABI issue.
>
> At some point, we'll break the C ABI to fix this, and with it the C++
> ABI -- for programs that use this extended type.
>
> 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.
2002-08-06 Jakub Jelinek <jakub@redhat.com>
* config/i386/mmintrin.h (__m64): Make the type 64-bit aligned.
--- gcc/config/i386/mmintrin.h.jj 2002-01-12 08:38:49.000000000 +0100
+++ gcc/config/i386/mmintrin.h 2002-08-06 20:05:02.000000000 +0200
@@ -31,7 +31,7 @@
#define _MMINTRIN_H_INCLUDED
/* The data type intended for user use. */
-typedef unsigned long long __m64;
+typedef unsigned long long __m64 __attribute__ ((__aligned__ (8)));
/* Internal data types for implementing the intrinsics. */
typedef int __v2si __attribute__ ((__mode__ (__V2SI__)));
Jakub