From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116609 invoked by alias); 15 Oct 2019 12:53:43 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 116593 invoked by uid 89); 15 Oct 2019 12:53:42 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:yddftju, H*MI:sk:eb45b82, H*MI:sk:yddftju, H*f:sk:yddftju X-HELO: mail-wr1-f68.google.com Received: from mail-wr1-f68.google.com (HELO mail-wr1-f68.google.com) (209.85.221.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 15 Oct 2019 12:53:40 +0000 Received: by mail-wr1-f68.google.com with SMTP id o28so1102978wro.7 for ; Tue, 15 Oct 2019 05:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I6UQmBvH3PYfstmpVVORF2WOdVLznPjK+J4kmZp8bcw=; b=vOPAY6AsVOUV4sJ3o56dPN29TjtBeNH3YNWU1w9SfbqQB0NwMHN7J95+EoX79qOr+K WRqZSq766+r7woXrcHFEm6MDX0XDLhxKG01P3jOVovCGFx++w9/rrpeBJiE2B9WtCBim 0FZeecAb1puobsjIQoqu1gwiRNhtPOIY0avsV07i87x61HZoxMcjWMu+vkhaSsMauRmv kJG5k0BYpWK9E6Q1j650ZNwT8xYqc6SRYj6mmLMz9+soEs8PCIlERIB3eKqBW1W7kkid vXvutxCKDMCrmo8EjSmTBvMcnbzAkzxHa3wwyHh8iesDbJ5V2iERoKR5OiEhI+408APg 76Fw== Return-Path: Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id 59sm46843085wrc.23.2019.10.15.05.53.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Oct 2019 05:53:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [patch] canonicalize unsigned [1,MAX] ranges into ~[0,0] From: Iain Sandoe In-Reply-To: Date: Tue, 15 Oct 2019 13:07:00 -0000 Cc: Jeff Law , gcc-patches , Andrew MacLeod , Rainer Orth Content-Transfer-Encoding: 7bit Message-Id: <733E0F44-F7E2-4B96-B173-B9F665ADB894@googlemail.com> References: <995b4560-6a76-6742-888f-eadbfb9ff9cc@redhat.com> <74fb2cf8-6312-6ae2-b620-3d36deb61080@redhat.com> <6a557c4c-d86b-7b7f-70c2-483fff2d5f59@redhat.com> <4a1ab265-cd1d-71b3-c2c7-31cd3667fa54@redhat.com> To: Aldy Hernandez X-SW-Source: 2019-10/txt/msg01091.txt.bz2 Hi Aldy, Rainer Orth wrote: >> >> On 10/15/19 7:58 AM, Rainer Orth wrote: >>> Hi Aldy, >>> >>>>>> ~[0,0] has been the accepted way for a long time, I'd really prefer to >>>>>> keep that (for now). >>>>> It has. Very true. But I don't necessarily think that means we should >>>>> be introducing even more of 'em. >>> [...] >>>> Happily, normalizing into ~0 for signed and [1,MAX] for unsigned, >>>> simplified the patch because it on longer needs tweaks to >>>> ranges_from_anti_range. >>>> >>>> OK for trunk? >>> >>> the new testcase FAILs on several (all?) 32-bit targets: >>> >>> +FAIL: gcc.dg/tree-ssa/evrp4.c scan-tree-dump evrp "\\\\[1B, -1B\\\\]" >> >> That's unfortunate. >> >> Is this the only test that is failing? > > it's the only on on Solaris/SPARC and Solaris/x86. Haven't checked > other affected targets, though. > >>> I'm seeing this on 32-bit i386-pc-solaris2.11 and sparc-sun-solaris2.11, >>> with more reports for armv8l, pru, and s390x. >>> >>> Comparing the dumps between 64 and 32-bit, I see >>> >>> -_1: int * [1B, -1B] >>> +_1: int * [1B, 4294967295B] >> >> I wonder why 32-bit targets at displaying 4294967295 instead of -1. Or are >> pointers 64-bits here? > > No, it's a pure 32-bit target. The compiler is 32-bit, too, but > bi-arch (32 and 64-bit). identical result on i686-darwin9, also a pure32b target (with a 64b multilb). Iain