--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
03:17 ---
Fixed in 4.0; will not be fixed in 3.4.x.
--
What|Removed |Added
Status|ASSIGNE
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
03:16 ---
Eric --
Never mind; test results aren't looking good. It looks like those comments
about offsetof were there for a reason. I'm still going to try applying the
patch to mainline -- but I don't think there
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-10
02:49 ---
The reason that this happens when the type assigned is a class types is that
those types have overloaded operator=. There's always an implicit operator=,
even if one is not declared explicitly, with a "thi
--- Additional Comments From ebotcazou at libertysurf dot fr 2005-03-31
06:30 ---
Subject: Re: [3.4 Regression] -fstrict-aliasing causes incorrect scheduling
> I think it's fixable. I'm not sure exactly why the C++ front-end is
> inserting the additional operations, but they're certai
--- Additional Comments From mark at codesourcery dot com 2005-03-31 00:54
---
Subject: Re: [3.4 Regression] -fstrict-aliasing causes incorrect
scheduling
ebotcazou at gcc dot gnu dot org wrote:
> --- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-30
> 10:53 -
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-30
10:53 ---
Hum... type-punning simply doesn't work in this case with the C++ compiler, but
does work with the C compiler. The problem is that:
union u {
x_uint64_t first;
x_uint32_t
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
19:43 ---
Investigating.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ebo
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-03-29
19:19 ---
Confirmed in 3.4.x, probably another incarnation of the infamous stack slot
sharing problem in 3.x when type-based aliasing is enabled.
As as side note, -fschedule-insns makes little sense without -mcpu=x
