Bug 17322 - [4.0 Regression] initializer folding broken
Summary: [4.0 Regression] initializer folding broken
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.0
Assignee: Richard Henderson
URL:
Keywords: rejects-valid
Depends on:
Blocks: 16989 16620
  Show dependency treegraph
 
Reported: 2004-09-04 18:54 UTC by Joseph S. Myers
Modified: 2004-09-13 14:15 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2004-09-08 21:12:10


Attachments
proposed patch (1.01 KB, patch)
2004-09-09 09:53 UTC, Richard Henderson
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph S. Myers 2004-09-04 18:54:12 UTC
Recent changes to the handling of structure references for C have broken
the folding of some valid initializers.

struct s { int a; int b[1]; };
struct s x;
int *y = ((struct s *)&x.a)->b;

involves a valid address constant, but is now wrongly rejected with

t.c:3: error: initializer element is not constant
Comment 1 Andrew Pinski 2004-09-07 07:46:45 UTC
This would be caused by RTH's patch, not to lower &a.b into &a + offsetof(a,b)
Comment 2 Richard Henderson 2004-09-08 21:12:09 UTC
Testing patch.
Comment 3 Richard Henderson 2004-09-09 09:53:13 UTC
Created attachment 7077 [details]
proposed patch

I'm not sure I understand the distinction between require_constant_value and
require_constant_elements here.  Am I allowing too much by relying on 
initializer_constant_valid_p all the time instead of trying to figure out how
to get TREE_CONSTANT propagated in such convoluted circumstances?
Comment 4 Joseph S. Myers 2004-09-09 12:11:39 UTC
Subject: Re:  [3.5 Regression] initializer folding broken

On Thu, 9 Sep 2004, rth at gcc dot gnu dot org wrote:

> I'm not sure I understand the distinction between require_constant_value and
> require_constant_elements here.  Am I allowing too much by relying on 
> initializer_constant_valid_p all the time instead of trying to figure out how
> to get TREE_CONSTANT propagated in such convoluted circumstances?

require_constant_value means a static initializer.  
require_constant_elements means either that or an automatic aggregate 
initializer in pedantic C90 mode.  Jakub could perhaps have put more 
comments in when overhauling this code.

I don't really suppose TREE_CONSTANT is going to be helpful here.  I think 
the right thing for this bug is simply to get back to accepting all forms 
of address constants we traditionally accepted (i.e. things that fold to 
address of object/function +/- a constant, possibly with various pointer 
casts and element and array accesses, with addresses then taken, involved, 
or that fold to constant cast to pointer type with the same operations 
involved).  I'd deal with rejecting the few such cases that are outside my 
model if implementing constant expressions properly, but that now seems 
unlikely.

Comment 5 CVS Commits 2004-09-09 17:36:46 UTC
Subject: Bug 17322

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	rth@gcc.gnu.org	2004-09-09 17:36:42

Modified files:
	gcc            : ChangeLog c-typeck.c 
Added files:
	gcc/testsuite/gcc.dg: pr17322.c 

Log message:
	PR c/17322
	* c-typeck.c (valid_compound_expr_initializer): Use only
	initializer_constant_valid_p, and not TREE_CONSTANT.
	(digest_init): Likewise.
	(output_init_element): Likewise.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.5332&r2=2.5333
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.368&r2=1.369
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr17322.c.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 6 Richard Henderson 2004-09-09 17:40:08 UTC
Fixed.