From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-179848-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 15897 invoked by alias); 15 Aug 2013 11:36:00 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 15888 invoked by uid 89); 15 Aug 2013 11:36:00 -0000
X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W autolearn=ham version=3.3.2
Received: from c62.cesmail.net (HELO c62.cesmail.net) (216.154.195.54)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Thu, 15 Aug 2013 11:35:59 +0000
Received: from unknown (HELO delta2) ([192.168.1.50])  by c62.cesmail.net with ESMTP; 15 Aug 2013 07:35:57 -0400
Received: from cust213-dsl91-135-11.idnet.net	(cust213-dsl91-135-11.idnet.net [91.135.11.213]) by webmail.spamcop.net	(Horde MIME library) with HTTP; Thu, 15 Aug 2013 07:35:57 -0400
Message-ID: <20130815073557.i2u9oatlskw84k8s-nzlynne@webmail.spamcop.net>
Date: Thu, 15 Aug 2013 11:56:00 -0000
From: Joern Rennecke <joern.rennecke@embecosm.com>
To: Richard Biener <rguenther@suse.de>
Cc: gcc@gcc.gnu.org
Subject: ssa-pre-21.c / PRE for truncated indices
MIME-Version: 1.0
Content-Type: multipart/mixed;	boundary="=_4bz7dzwyb4f1"
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
X-Virus-Found: No
X-SW-Source: 2013-08/txt/msg00174.txt.bz2

This message is in MIME format.

--=_4bz7dzwyb4f1
Content-Type: text/plain;
	charset=ISO-8859-15;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Content-length: 469

I see that gcc.dg/tree-ssa/ssa-pre-21.c fails for avr.
The computation of k + 1L is done as unsigned int (16 bit),
but later ++k is performed as unsigned long (32 bit), and thus
array[k+1] is not re-used.

Is this to be considered a big in the optimizers for not
optimizing this, or in the testsuite for insisting that it
should be?

FWIW, equivalent behaviour can be seen natively on
i686-pc-linux-gnu by replacing "long" with "long long",
as shown in the attachment.

--=_4bz7dzwyb4f1
Content-Type: text/x-chdr;
	charset=ISO-8859-1;
	name="ssa-pre-21-ll.c"
Content-Disposition: inline;
	filename="ssa-pre-21-ll.c"
Content-Transfer-Encoding: 7bit
Content-length: 356

/* { dg-do compile } */
/* { dg-options "-O2 -fdump-tree-pre" } */

long long
NumSift (long long *array, unsigned long long k)
{
  if (array[k] < array[k + 1LL])
    ++k;
  return array[k];
}

/* There should be only two loads left.  */

/* { dg-final { scan-tree-dump-times "= \\\*\[^\n;\]*;" 2 "pre" } } */
/* { dg-final { cleanup-tree-dump "pre" } } */

--=_4bz7dzwyb4f1--