| Message ID | 20131021151322.GM10967@redhat.com |
|---|---|
| State | New |
| Headers | show |
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 <polacek@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. Your call -- fine as-is or you can let BOOLEAN_TYPEs through with a pre-approved patch. jeff
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 <polacek@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
--- gcc/fold-const.c.mp 2013-10-21 16:12:31.494179417 +0200 +++ gcc/fold-const.c 2013-10-21 16:19:08.673580775 +0200 @@ -4984,12 +4984,16 @@ fold_range_test (location_t loc, enum tr int in0_p, in1_p, in_p; tree low0, low1, low, high0, high1, high; bool strict_overflow_p = false; - tree lhs = make_range (op0, &in0_p, &low0, &high0, &strict_overflow_p); - tree rhs = make_range (op1, &in1_p, &low1, &high1, &strict_overflow_p); - tree tem; + tree tem, lhs, rhs; const char * const warnmsg = G_("assuming signed overflow does not occur " "when simplifying range test"); + if (!INTEGRAL_TYPE_P (type)) + return 0; + + lhs = make_range (op0, &in0_p, &low0, &high0, &strict_overflow_p); + rhs = make_range (op1, &in1_p, &low1, &high1, &strict_overflow_p); + /* If this is an OR operation, invert both sides; we will invert again at the end. */ if (or_op) --- gcc/testsuite/gcc.dg/gomp/pr58809.c.mp 2013-10-21 16:12:13.333114856 +0200 +++ gcc/testsuite/gcc.dg/gomp/pr58809.c 2013-10-21 16:11:49.296022857 +0200 @@ -0,0 +1,13 @@ +/* PR middle-end/58809 */ +/* { dg-do compile } */ +/* { dg-options "-fopenmp -O" } */ + +int i; +#pragma omp threadprivate (i) + +void foo() +{ + _Complex int j; +#pragma omp parallel copyin (i) reduction (&&:j) + ; +}