This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 1/2] simplify-rtx: The truncation of an IOR can have all bits set (PR81423)
- From: Jeff Law <law at redhat dot com>
- To: Segher Boessenkool <segher at kernel dot crashing dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 8 Aug 2017 10:27:39 -0600
- Subject: Re: [PATCH 1/2] simplify-rtx: The truncation of an IOR can have all bits set (PR81423)
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 52F2B7F7B0
- References: <0926f163a7f91c101e34cff5cf7926506d208517.1500380707.git.segher@kernel.crashing.org> <c4872b98-7825-a8ec-c007-268b1db8b49e@redhat.com> <20170724085051.GT13471@gate.crashing.org> <d84ebe46-c3e7-db2f-0b5c-56b14fb38509@redhat.com> <20170725112549.GE13471@gate.crashing.org> <20170807223333.GJ13471@gate.crashing.org>
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 <segher@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