[Bug c++/16381] [3.3/4.0 Regression] Structure layout bug

2004-10-28 Thread mmitchel at gcc dot gnu dot org 

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-10-28 06:00 
---
On i686-pc-linux-gnu, with both GCC 3.4.2 and GCC 4.0, I see :

__m128 size 16, align 16
Quad   size 16, align 16
Base1 32 Derived1 32 Offset 20
Base2 32 Derived2 48 Offset 32

I am building a Cygwin cross compiler to check there.

-- 
   What|Removed |Added

  Known to fail|3.3.4 4.0   |3.3.4 4.0.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16381

[Bug c++/16381] [3.3/4.0 Regression] Structure layout bug

2004-10-28 Thread mmitchel at gcc dot gnu dot org 

--- Additional Comments From mmitchel at gcc dot gnu dot org  2004-10-28 06:18 
---
On Cygwin, I still get 24 32 24 for Base 2.

The reason turns out to have nothing to do with PODs.  Rather, it is due to the
fact that on Cygwin, BIGGEST_FIELD_ALIGNMENT is set to 8 bytes.  So, even though
the __m128 type has 16-byte alignment, Base 2 has only 8 byte alignment, which
results in a size of 24 bytes.

-- 
   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16381

[Bug c++/16381] [3.3/4.0 Regression] Structure layout bug

2004-10-28 Thread dannysmith at users dot sourceforge dot net 

--- Additional Comments From dannysmith at users dot sourceforge dot net  
2004-10-28 07:14 ---
Isn't this a bug in cygming.h then?  Would something like this
still retain  MSVC compatibility while allowing logical alignment
for SSE[2] types?

/* This is only needed in libobjc. There we use 8-byte alignment to be
   consistent with  TARGET_ALIGN_DOUBLE default. Otherwise the
   i386 version of ADJUST_FIELD_ALIGN  will do the right thing (i.e
   not force 4-byte alignment on doubles and long longs) since 
   TARGET_ALIGN_DOUBLE is set. */
#ifdef IN_TARGET_LIBS
#undef  BIGGEST_FIELD_ALIGNMENT
#define BIGGEST_FIELD_ALIGNMENT 64
#endif

Danny


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16381