On Wed, Mar 14, 2012 at 11:39 AM, Frederic Riss <frederic.r...@gmail.com> wrote: > On 13 March 2012 22:36, Frédéric RISS <frederic.r...@gmail.com> wrote: >> In 4.7, the COND_EXPR has become a GIMPLE_TERNARY_RHS rhs_class, meaning >> that it won't use the expand_assigment path in expand_gimple_stmt_1, but >> will use straight expression expansion which will generate control flow >> RTL for the COND_EXPR. >> >> Should this be considered a code generation regression, or should the >> MAX_EXPR trees be generated at some other point in the middle-end ? > > This one-liner fixes this code generation regression on my simple testcase: > > diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c > index bde15f6..6fd09f5 100644 > --- a/gcc/cfgexpand.c > +++ b/gcc/cfgexpand.c > @@ -3776,6 +3803,7 @@ expand_gimple_basic_block (basic_block bb) > { > basic_block new_bb; > > + fold_stmt_inplace (&gsi); > stmt = gsi_stmt (gsi); > > /* If this statement is a non-debug one, and we generate debug > > > Doing that at expansion time looks like papering over some other issue though.
Can you check where the COND_EXPR is introduced? That place should be fixed to properly fold. Richard. > Fred