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
- From: Jeffrey A Law <law at redhat dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Thu, 24 Jun 2004 11:59:15 -0600
- Subject: Re: TREE_SIDE_EFFECTS vs STATEMENT_LIST vs recompute_side_effects
- Organization: Red Hat, Inc
- References: <1088098249.2772.49.camel@speedy> <20040624175202.GA31885@redhat.com>
- Reply-to: law at redhat dot com
On Thu, 2004-06-24 at 11:52, Richard Henderson wrote:
> > That seems awfully wrong. In gimple, COND_EXPRs shouldn't have any
> > side effects whatsoever.
>
> Disagree.
Huh? Really, what kind of side effects do you expect to see on
COND_EXPRs?
> 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.
This is set if any subexpression is a function call, a side effect or
a
reference to a volatile variable. In a ..._DECL, this is set only if
the
declaration said `volatile'. This will never be set for a constant.
*/
#define TREE_SIDE_EFFECTS(NODE) \
(NON_TYPE_CHECK (NODE)->common.side_effects_flag)
> The argument is true as a whole for the COND_EXPR both before and
> after the lowering.
>
> What is the deeper issue?
The deeper issue is in this case the bit propagates up through
the COND_EXPR, eventually to a COMPONENT_REF.
jeff