--- Additional Comments From rth at gcc dot gnu dot org 2005-01-26 15:24
---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-01-26
15:21 ---
Subject: Bug 19515
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2005-01-26 15:20:53
Modified files:
gcc: ChangeLog expr.c gimplify.c tree.h
A
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 18:03
---
(In reply to comment #12)
> But, what about structures that contain a union?
We'll need to consider the question "do we need to clear" one nesting
level at a time, and propagate it up.
--
http://gcc.gnu.or
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-20
11:49 ---
> For structures, this would mean that any structure with holes would get
> cleared. Which would clearly pessimize a very common case.
I considered that too. But, what about structures that
contain a union
--- Additional Comments From rth at gcc dot gnu dot org 2005-01-20 11:28
---
(In reply to comment #7)
> So we cannot use count_type_elements in gimplify_init_constructor.
Well, not for unions anyway.
> I think we should somehow compute the size of the CONSTRUCTOR and compare
> it wit
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-20
09:31 ---
> Ehm?? "union { int i; char c[256]; }"
Doesn't look much buggier than what we currently have... maybe take the max on
all the fields then? That said, I don't know what count_type_elements is for,
it is
--- Additional Comments From stevenb at suse dot de 2005-01-20 09:26
---
Subject: Re: [4.0 Regression] Violation of C99 6.7.8 =?utf-8?q?=A721_for?=
unions
> Can't we compute the result for unions based on the type of the first
> member?
Ehm?? "union { int i; char c[256]; }"
However
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-01-20
09:15 ---
> From expr.c:count_type_elements:
>
> case UNION_TYPE:
> case QUAL_UNION_TYPE:
> {
> /* Ho hum. How in the world do we guess here? Clearly it isn't
>right to cou
