[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
-- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-20 11:28 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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 gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.dg: 20041219-1.c Log message: gcc/ PR middle-end/18191 PR middle-end/18965 PR middle-end/18999 * expr.c (categorize_ctor_elements_1): Count the total number of elements in the constructor. (categorize_ctor_elements): Return it in a new argument. * tree.h (categorize_ctor_elements): Adjust prototype. * gimplify.c (gimplify_init_ctor_eval_range): New. (gimplify_init_ctor_eval): Gimplify RANGE_EXPR. (gimplify_init_constructor): Block clear the object if the constructor has fewer elements than the object type. Only try to add assignments to individual elements when we have to. testsuite/ * gcc.dg/20041219-1.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6897&r2=2.6898 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcc&r1=1.761&r2=1.762 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gimplify.c.diff?cvsroot=gcc&r1=2.93&r2=2.94 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree.h.diff?cvsroot=gcc&r1=1.667&r2=1.668 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4783&r2=1.4784 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/20041219-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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||18999 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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 type_contains_placeholder_p (TYPE_DOMAIN (type)); But a VECTOR_TYPE doesn't have a TYPE_DOMAIN, so we ICE. This is the cause of the gcc.dg/i386-3dnow-[12].c failures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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 gimplify.c:2404 2404 gcc_assert (TREE_CODE (purpose) != RANGE_EXPR); the test case is this: int *x = new int [2] (); For some reason the constructor has three (!) elements instead of two, which probably causes this bug to be hidden in the existing code. The other two are also cases where the "cleared" flag used to be set when it really shouldn't have been, so that's another latent but that my patch uncovers :-( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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 gnu |steven at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-15 15:29 --- This is RTH's code. -- What|Removed |Added CC||rth at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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
we'd need to *find* the elements that are not present, and that
requires trickery to avoid quadratic compile-time behavior in
large cases or excessive memory use in small cases. */
else
{
HOST_WIDE_INT len = list_length (elt_list);
if (TREE_CODE (type) == ARRAY_TYPE)
{
tree nelts = array_type_nelts (type);
if (!host_integerp (nelts, 1)
|| tree_low_cst (nelts, 1) + 1 != len)
cleared = true;
}
else if (len != fields_length (type))
cleared = true;
}
We have this expr:
objD.1485 = {{.sD.1468=(const charD.1 *) (charD.1 *) "m0"}, {}}
The type of the constructor is an ARRAY_TYPE, nelts == 1, and len (the length
of the constructor) is 2. So nelts+1 == 2, and we set cleared = true. But
we ignore the fact that the second element of the constructor is empty, and
that the first one is incomplete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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 that don't have explicit initializers, so if not all elements are initialized we keep the original MODIFY_EXPR, we just remove all of the constructor elements. */ static enum gimplify_status gimplify_init_constructor (tree *expr_p, tree *pre_p, tree *post_p, bool want_value) So apparently we fail here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
-- What|Removed |Added Severity|normal |critical http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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 CC||jsm28 at gcc dot gnu dot ||org, mark at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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 first. Don't do this if TARGET is a register whose mode size isn't equal to SIZE since clear_storage can't handle this case. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
[Bug middle-end/18191] [4.0 Regression] Struct member is not getting default-initialized
--- 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 middle-end (the gimplifier) issue as the C front-end has the same problem
(the C standard
defines it in 6.7.8/21).
The C example:
#include
typedef struct S {
const char* s;
int i;
} S;
void foo() {
// Put some garbage on the stack
S dummy[2];
for (unsigned i = 0; i < sizeof(dummy); i++)
((char *)&dummy)[i] = -1;
}
int bar() {
// Allocate object on the stack
S obj[2] = {
{"m0"},
{ }
};
// Assume fields those not explicitly initialized
// are default initialized to 0 [8.5.1/7 and 8.5/5]
if (obj[0].i == 0){
return 0;
} else {
printf("Failed: obj[0].i == '%d', expecting '0'\n", obj[0].i);
return 1;
}
};
int main(){
foo();
return bar();
}
Note we get a warning which is bogus:
pr18191.c:23: warning: 'obj$0$i' is used uninitialized in this function
--
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c++ |middle-end
Ever Confirmed||1
Keywords||wrong-code
Last reconfirmed|-00-00 00:00:00 |2004-10-28 14:19:42
date||
Summary|Struct member is not getting|[4.0 Regression] Struct
|default-initialized |member is not getting
||default-initialized
Target Milestone|--- |4.0.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18191
