This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: TREE_SIDE_EFFECTS vs STATEMENT_LIST vs recompute_side_effects
On Thu, Jun 24, 2004 at 11:59:15AM -0600, Jeffrey A Law wrote:
> Huh? Really, what kind of side effects do you expect to see on
> COND_EXPRs?
Some substatement with side effects, propagated up.
> > Sure, but the GOTO_EXPRs that will replace the STATEMENT_LISTs
> > *also* have side effects. The side effect is a control transfer.
> That's radically different from the docs for TREE_SIDE_EFFECTS:
>
> /* In any expression, decl, or constant, nonzero means it has side
> effects or
> reevaluation of the whole expression could produce a different value.
You don't think control flow transfer is a side effect?
I certainly do.
> The deeper issue is in this case the bit propagates up through
> the COND_EXPR, eventually to a COMPONENT_REF.
So not COND_EXPR the if statement, but COND_EXPR the ternary operator.
In which case there *isn't* a control flow transfer, since there's a
known join at the end, and I agree, in absense of anything else, does
not have side effects.
But back to your example,
(cond ? iftmp = x : iftmp = y)
we *still* have side effects, even discounting the statement_list.
Of course, this should have been gimplified to the above, put in a
statement context, and stuffed in a pre-queue. So by the time you
get to the COMPONENT_REF, we only have iftmp, which doesn't have
side effects.
So I guess I must ask again: what's the deeper issue? Or the test
case and I'll have a look at it.
r~