This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: DCE eliminating valid statement for ACATS c34007p
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: stevenb at suse dot de
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 6 Sep 05 09:37:12 EDT
- Subject: Re: DCE eliminating valid statement for ACATS c34007p
Because it doesn't make sense to take the address of a COMPOUND_EXPR
for example? As Kenner puts it himself:
"This turned out to be the "well known" problem that the Ada
front end is making an ADDR_EXPR of odd things, in this case
a COMPOUND_EXPR."
So there you have it: a well known problem in the Ada front end, not
a bug in the gimplifier.
No, I meant "well known" as in "we've discussed it here before".
There's certainly no problem with an ADDR_EXPR of a COMPOUND_EXPR
conceptually. In C form, & (some_function (), foobar) makes perfect sense
and is equivalent to (some_function (), &foobar). Indeed the case that was
discussed on the list was an ADDR_EXPR of a CONSTRUCTOR. Here, the case is
an ADDR_EXPR of a COMPOUND_EXPR whose result is a SAVE_EXPR.
What would be your proposal as to which nodes it's valid to have as operands
of an ADDR_EXPR? We certainly never even thought of such a rule before.