On 08/07/2017 04:33 PM, Segher Boessenkool wrote: > On Tue, Jul 25, 2017 at 06:25:49AM -0500, Segher Boessenkool wrote: >> On Mon, Jul 24, 2017 at 04:06:39PM -0600, Jeff Law wrote: >>>> 2017-07-24 Segher Boessenkool <seg...@kernel.crashing.org> >>>> >>>> gcc/testsuite/ >>>> PR rtl-optimization/81423 >>>> * gcc.c-torture/execute/pr81423.c: New testcase. >>> I think int32plus just indicates ints are at least 32 bits. But a long >>> or long long could still be just 32 bits. so int32plus && long_neq_int, >>> to ensure that long/long long are 64 bits? >> >> Well, long long is required to be 64 bits or more by the C standard. >> But some GCC targets do not follow that, with certain options at least. >> >> It looks like that test actually requires long long to be *exactly* >> 64 bits. I'll modify the test to test for that. > > So I came up with the following. Is this okay for trunk? (Tested on > powerpc64-linux and x86_64-linux, both with both -m32 and -m64, and > tested it does fail on x86 without the patches to fix the bug). > > > Segher > > > diff --git a/gcc/testsuite/gcc.c-torture/execute/pr81423.c > b/gcc/testsuite/gcc.c-torture/execute/pr81423.c > new file mode 100644 > index 0000000..731aa8f > --- /dev/null > +++ b/gcc/testsuite/gcc.c-torture/execute/pr81423.c > @@ -0,0 +1,36 @@ > +extern void abort (void); > + > +unsigned long long int ll = 0; > +unsigned long long int ull1 = 1ULL; > +unsigned long long int ull2 = 12008284144813806346ULL; > +unsigned long long int ull3; > + > +unsigned long long int __attribute__ ((noinline)) > +foo (void) > +{ > + ll = -5597998501375493990LL; > + > + ll = (5677365550390624949L - ll) - (ull1 > 0); > + unsigned long long int ull3; > + ull3 = (unsigned int) > + (2067854353L << > + (((ll + -2129105131L) ^ 10280750144413668236ULL) - > + 10280750143997242009ULL)) >> ((2873442921854271231ULL | ull2) > + - 12098357307243495419ULL); > + > + return ull3; > +} > + > +int > +main (void) > +{ > + /* We need a long long of exactly 64 bits for this test. */ > + ll--; > + if (ll != 0xffffffffffffffffULL) > + return 0; I think we've used sizeof to check this in the past. But I'm not wed to that approach. If it's working for you, then let's go with it.
jeff