--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-12-20
11:27 ---
Subject: Bug 18191
CVSROOT:/cvs/gcc
Module name:gcc
Changes by: [EMAIL PROTECTED] 2004-12-20 11:26:47
Modified files:
gcc: ChangeLog expr.c gimplify.c tree.h
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20
11:28 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--
Bug 18191 depends on bug 18999, which changed state.
Bug 18999 Summary: gimplify_init_ctor_eval does not support RANGE_EXPRs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18999
What|Old Value |New Value
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-19
13:03 ---
Updated patch posted.
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01384.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-18
00:22 ---
Posted a patch:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01322.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-16
18:07 ---
Someone had a bad day:
case ARRAY_TYPE:
case VECTOR_TYPE:
/* We're already checked the component type (TREE_TYPE), so just check
the index type. */
return
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-16
23:52 ---
The new4.C failure is, in fact, PR18999.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-17
01:35 ---
(In reply to comment #15)
The new4.C failure is, in fact, PR18999.
I added a patch to PR18999 which implements the loop version for handling
RANGE_EXPR.
--
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
14:46 ---
I thought this could be an SRA bug, but it also happens with optimization
disabled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
14:56 ---
From gimplify.c:
/* A subroutine of gimplify_modify_expr. Break out elements of a
CONSTRUCTOR used as an initializer into separate MODIFY_EXPRs.
Note that we still need to clear any elements
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
15:16 ---
methinks the bug is in this code:
/* ??? This bit ought not be needed. For any element not present
in the initializer, we should simply set them to zero. Except
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
15:29 ---
This is RTH's code.
--
What|Removed |Added
CC|
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
20:45 ---
Might as well make it mine.
--
What|Removed |Added
AssignedTo|unassigned at gcc dot
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-16
07:56 ---
The new4.C failure happens because we trip over an assert:
#1 0x00629120 in gimplify_init_ctor_eval (object=0x2a95999bc0,
list=0x2a9599bf00,
pre_p=0x7fbfffca08, cleared=0 '\0') at
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
14:50 ---
We never call store_constructor at all for this test case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
22:21 ---
...but that's probably because of a bug already pointed out by rth. I'll
retest the fixed patch. *sigh*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15
22:20 ---
The patch causes three new failures:
g++.dg/init/new4.C (test for excess errors)
gcc.dg/i386-3dnow-1.c (test for excess errors)
gcc.dg/i386-3dnow-2.c (test for excess errors)
--
--- Additional Comments From steven at gcc dot gnu dot org 2004-11-28
13:16 ---
Since this is language specific behavior, I think this is a C/C++ front
end bug. The front end should produce the default initializers. What
do our C/C++ FE maintainers think about this?
--
--
What|Removed |Added
Severity|normal |critical
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-08
15:06 ---
Note expand used to do this for us:
/* If the constructor has fewer fields than the structure or
if we are initializing the structure to mostly zeros, clear
the whole structure
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-28 14:19
---
Confirmed, a regression but I don't know if this is a middle-end problem or a
front-end problem.
The front-end produces the following code:
struct S obj[2] = {{.s=(const char *) m0}, {}};
This is a
21 matches
Mail list logo
