On Mon, Oct 21, 2013 at 10:56:52AM -0600, Jeff Law wrote: > On 10/21/13 09:13, Marek Polacek wrote: > >In this PR (well, in the first testcase in it), the problem was that > >fold_range_test got op0 and op1 of a COMPLEX_TYPE, subsequent call > >of make_range then failed because it wants to create an integer constant > >using build_int_cst - and that can't handle COMPLEX_TYPE. Also, > >we can't just compare complex numbers, so I think it's sane to bail out > >if fold_range_test isn't dealing with integer types... > > > >I didn't want to put the check between the declarations, so the > >make_range calls were moved slightly below. > > > >Regtested/bootstrapped on x86_64-linux, ok for trunk? > > > >2013-10-21 Marek Polacek <pola...@redhat.com> > > > > PR middle-end/58809 > > * fold-const.c (fold_range_test): Return 0 if the type is not > > an integral type. > >testsuite/ > > * gcc.dg/gomp/pr58809.c: New test. > For exceedingly annoying reasons BOOLEAN_TYPE is not considered an > integral type. You might consider letting fold_range_test do it's > thing on BOOLEAN_TYPEs, though I'd be surprised if that matters in > practice.
Really? In tree.h I can see #define INTEGRAL_TYPE_P(TYPE) \ (TREE_CODE (TYPE) == ENUMERAL_TYPE \ || TREE_CODE (TYPE) == BOOLEAN_TYPE \ || TREE_CODE (TYPE) == INTEGER_TYPE) > Your call -- fine as-is or you can let BOOLEAN_TYPEs through with a > pre-approved patch. ...so I'm keeping the patch as-is. Thanks, Marek