[Committed] Fix latent "tuples" bug in fold-const.c

Roger Sayle roger@eyesopen.com
Thu Jan 4 23:00:00 GMT 2007


Some work I was doing in the gfortran front-end has exposed a latent bug
in the middle-end caused by Aldy's recent "tuples" work.  To reduce
memory, the tree-ssa optimizers now use a light-weight tree node called
GIMPLE_MODIFY_STMT instead of the regular MODIFY_EXPR.  One side-effect is
that these special nodes don't have a type, hence at several points we now
generate COMPOUND_EXPRs of the form "(a=b;a)" to model the fact that
assignments may be required to have a value.  This unfortunately, can lead
to problems, for example if we call fold_convert to cast this expression
to void, where we strip off the wrapper and return a raw
GIMPLE_MODIFY_STMT that we then attempt to cast with a NOP_EXPR. 
Unfortunately, the NOP_EXPR code immediately checks the type of it's
argument using TREE_TYPE, and we abort.

My opinion is that mixing/nesting expression and non-expression tree codes
arbitrarily is probably a bad idea, and the current approach of
disallowing non-gimple trees, even temporarily, during the tree-ssa passes
is probably over simplistic.  Fortunately, it looks like once many of the
"FIXME tuples" comments in the middle-end are addressed some of these
restrictions can be relaxed, and similar latent bugs eliminated.

The patch below fixes this particular issue for me.  It has been tested on
x86_64-unknown-linux-gnu with a full "make bootstrap", all default
languages, and regression tested with a top-level "make -k check" with no
new failures.

Committed to mainline as revision 120451.

2007-01-04  Roger Sayle  <roger@eyesopen.com>

        * fold-const.c (fold_convert): When casting an expression to void,
        fold_ignored_result may discover a GIMPLE_MODIFY_STMT which doesn't
        have a type.  Instead of attempting to build a NOP_EXPR, return
        these "special" trees directly.

Roger
--
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patchf0.txt
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20070104/474c4e72/attachment.txt>


More information about the Gcc-patches mailing list