* [Bug c++/16381] Structure layout bug
2004-07-06 9:11 [Bug c++/16381] New: Structure layout bug zhangjie at magima dot com dot cn
@ 2004-07-06 15:42 ` pinskia at gcc dot gnu dot org
2004-08-16 10:47 ` [Bug c++/16381] [3.3/3.4/3.5 Regression] " giovannibajo at libero dot it
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-06 15:42 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From pinskia at gcc dot gnu dot org 2004-07-06 15:42 -------
Related to 10179.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16381
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/16381] [3.3/3.4/3.5 Regression] Structure layout bug
2004-07-06 9:11 [Bug c++/16381] New: Structure layout bug zhangjie at magima dot com dot cn
2004-07-06 15:42 ` [Bug c++/16381] " pinskia at gcc dot gnu dot org
@ 2004-08-16 10:47 ` giovannibajo at libero dot it
2004-08-17 6:39 ` [Bug c++/16381] [3.3/3.5 " mmitchel at gcc dot gnu dot org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: giovannibajo at libero dot it @ 2004-08-16 10:47 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From giovannibajo at libero dot it 2004-08-16 10:47 -------
3.4.0 gives this:
__m128 size 16, align 16
Quad size 16, align 16
Base1 32 Derived1 32 Offset 20
Base2 24 Derived2 24 Offset 20
3.5.0 20040626 gives this:
__m128 size 16, align 16
Quad size 16, align 16
Base1 32 Derived1 32 Offset 20
Base2 32 Derived2 48 Offset 32
Jie's expected result (from a mail of him) is:
__m128 size 16, align 16
Quad size 16, align 4
Base1 20 Derived1 24 Offset 20
Base2 32 Derived2 48 Offset 32
Given the importance of this, and the inconsistencies between 3.3/3.4/3.5, I'll
confirm this bug as a regression. ABI gurus can revisit this, and check which
version is correct (if any), and what needs fixing.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |giovannibajo at libero dot
| |it
Severity|normal |critical
Status|UNCONFIRMED |NEW
Ever Confirmed| |1
Keywords| |ABI, wrong-code
Known to fail| |3.3.4 3.4.0 3.5.0
Last reconfirmed|0000-00-00 00:00:00 |2004-08-16 10:47:41
date| |
Summary|Structure layout bug |[3.3/3.4/3.5 Regression]
| |Structure layout bug
Target Milestone|--- |3.4.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16381
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/16381] [3.3/3.5 Regression] Structure layout bug
2004-07-06 9:11 [Bug c++/16381] New: Structure layout bug zhangjie at magima dot com dot cn
2004-07-06 15:42 ` [Bug c++/16381] " pinskia at gcc dot gnu dot org
2004-08-16 10:47 ` [Bug c++/16381] [3.3/3.4/3.5 Regression] " giovannibajo at libero dot it
@ 2004-08-17 6:39 ` mmitchel at gcc dot gnu dot org
2004-08-17 7:31 ` zhangjie at magima dot com dot cn
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2004-08-17 6:39 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From mmitchel at gcc dot gnu dot org 2004-08-17 06:39 -------
It's my opinion that GCC 3.4.x is correct, and 3.5 is wrong.
Jie's suggestion that Quad have alignment 4 does not make sense to me, given the
"__attribute__ ((aligned (16)))" on its member "x".
The distinction between GCC 3.4 and GCC 3.5 is that GCC 3.4 is treating Base2 as
a POD, where as GCC 3.5 is not. I see no reason why a struct containing
"__m128" should disqualify a type from being a POD, although clearly that is not
specified by the standard.
Therefore, I've retargeted this at GCC 3.5.
--
What |Removed |Added
----------------------------------------------------------------------------
Known to fail|3.3.4 3.4.0 3.5.0 |3.3.4 3.5.0
Summary|[3.3/3.4/3.5 Regression] |[3.3/3.5 Regression]
|Structure layout bug |Structure layout bug
Target Milestone|3.4.2 |3.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16381
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/16381] [3.3/3.5 Regression] Structure layout bug
2004-07-06 9:11 [Bug c++/16381] New: Structure layout bug zhangjie at magima dot com dot cn
` (2 preceding siblings ...)
2004-08-17 6:39 ` [Bug c++/16381] [3.3/3.5 " mmitchel at gcc dot gnu dot org
@ 2004-08-17 7:31 ` zhangjie at magima dot com dot cn
2004-08-17 9:53 ` zhangjie at magima dot com dot cn
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: zhangjie at magima dot com dot cn @ 2004-08-17 7:31 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From zhangjie at magima dot com dot cn 2004-08-17 07:30 -------
It seems that Giovanni refered this email from me
<http://gcc.gnu.org/ml/gcc/2004-06/msg00667.html>. But I made a mistake in it as
indicated by this email <http://gcc.gnu.org/ml/gcc/2004-06/msg00669.html>. And
the results in these emails came from a slightly different case
<http://gcc.gnu.org/ml/gcc/2004-06/msg00622.html>, in which Quad had no
constructor. Sorry, I should have written more clearly when I reported this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16381
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/16381] [3.3/3.5 Regression] Structure layout bug
2004-07-06 9:11 [Bug c++/16381] New: Structure layout bug zhangjie at magima dot com dot cn
` (3 preceding siblings ...)
2004-08-17 7:31 ` zhangjie at magima dot com dot cn
@ 2004-08-17 9:53 ` zhangjie at magima dot com dot cn
2004-08-17 10:04 ` zhangjie at magima dot com dot cn
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: zhangjie at magima dot com dot cn @ 2004-08-17 9:53 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From zhangjie at magima dot com dot cn 2004-08-17 09:53 -------
hi Giovanni, did you run the test on Linux? The result with gcc-3.5-20040815 on
cygwin is as same as the bug was reported.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16381
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/16381] [3.3/3.5 Regression] Structure layout bug
2004-07-06 9:11 [Bug c++/16381] New: Structure layout bug zhangjie at magima dot com dot cn
` (4 preceding siblings ...)
2004-08-17 9:53 ` zhangjie at magima dot com dot cn
@ 2004-08-17 10:04 ` zhangjie at magima dot com dot cn
2004-10-28 6:00 ` [Bug c++/16381] [3.3/4.0 " mmitchel at gcc dot gnu dot org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: zhangjie at magima dot com dot cn @ 2004-08-17 10:04 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From zhangjie at magima dot com dot cn 2004-08-17 10:04 -------
(In reply to comment #3)
>
> The distinction between GCC 3.4 and GCC 3.5 is that GCC 3.4 is treating Base2 as
> a POD, where as GCC 3.5 is not. I see no reason why a struct containing
> "__m128" should disqualify a type from being a POD, although clearly that is not
> specified by the standard.
>
I think "__m128" would better be treated as plain data type like int and long.
So I prefer the result of "3.5.0 20040626" in comment #2.
> Therefore, I've retargeted this at GCC 3.5.
Although I have not tested, I guess GCC 3.4.1 on cygwin will also give the wrong
result, whether "__m128" is treated as POD or not. So if we want to fix it on
cygwin, we'd better retarget it at GCC 3.4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16381
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/16381] [3.3/4.0 Regression] Structure layout bug
2004-07-06 9:11 [Bug c++/16381] New: Structure layout bug zhangjie at magima dot com dot cn
` (5 preceding siblings ...)
2004-08-17 10:04 ` zhangjie at magima dot com dot cn
@ 2004-10-28 6:00 ` mmitchel at gcc dot gnu dot org
2004-10-28 6:18 ` mmitchel at gcc dot gnu dot org
2004-10-28 7:14 ` dannysmith at users dot sourceforge dot net
8 siblings, 0 replies; 10+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2004-10-28 6:00 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/16381] [3.3/4.0 Regression] Structure layout bug
2004-07-06 9:11 [Bug c++/16381] New: Structure layout bug zhangjie at magima dot com dot cn
` (6 preceding siblings ...)
2004-10-28 6:00 ` [Bug c++/16381] [3.3/4.0 " mmitchel at gcc dot gnu dot org
@ 2004-10-28 6:18 ` mmitchel at gcc dot gnu dot org
2004-10-28 7:14 ` dannysmith at users dot sourceforge dot net
8 siblings, 0 replies; 10+ messages in thread
From: mmitchel at gcc dot gnu dot org @ 2004-10-28 6:18 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug c++/16381] [3.3/4.0 Regression] Structure layout bug
2004-07-06 9:11 [Bug c++/16381] New: Structure layout bug zhangjie at magima dot com dot cn
` (7 preceding siblings ...)
2004-10-28 6:18 ` mmitchel at gcc dot gnu dot org
@ 2004-10-28 7:14 ` dannysmith at users dot sourceforge dot net
8 siblings, 0 replies; 10+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2004-10-28 7:14 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 10+ messages in thread