This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]