--- 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
--- 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 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 count the
--- 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: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 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 with
--- 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 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.
--
