This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/17322] [3.5 Regression] initializer folding broken
- From: "jsm at polyomino dot org dot uk" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 9 Sep 2004 12:12:00 -0000
- Subject: [Bug c/17322] [3.5 Regression] initializer folding broken
- References: <20040904185412.17322.jsm28@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From jsm at polyomino dot org dot uk 2004-09-09 12:11 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17322