From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12416 invoked by alias); 1 Jul 2005 04:15:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12403 invoked by uid 22791); 1 Jul 2005 04:15:49 -0000 Received: from mail-out2.fuse.net (HELO smtp2.fuse.net) (216.68.8.175) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 01 Jul 2005 04:15:49 +0000 Received: from gx5.fuse.net ([216.68.17.142]) by smtp2.fuse.net (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050701041548.WLKE10827.smtp2.fuse.net@gx5.fuse.net> for ; Fri, 1 Jul 2005 00:15:48 -0400 Received: from dellpi.pinski.fam ([216.68.17.142]) by gx5.fuse.net (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP id <20050701041547.IJHK6448.gx5.fuse.net@dellpi.pinski.fam>; Fri, 1 Jul 2005 00:15:47 -0400 Received: from [10.0.0.80] (zhivago.i.pinski.fam [10.0.0.80]) by dellpi.pinski.fam (8.12.2/8.12.1) with ESMTP id j614FbQi005966; Fri, 1 Jul 2005 00:15:43 -0400 (EDT) In-Reply-To: References: <20050630220250.GA10768@synopsys.com> <20050630232531.GA11010@synopsys.com> <20050701012538.GA11465@synopsys.com> <1120187757.17986.14.camel@linux-009002243055> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Daniel Berlin , Joe Buck , "'gcc mailing list'" From: Andrew Pinski Subject: Re: Should GCC publish a general rule/warning due to it's default presumption of undefined signed integer overflow semantics? Date: Fri, 01 Jul 2005 04:15:00 -0000 To: Gabriel Dos Reis X-SW-Source: 2005-07/txt/msg00018.txt.bz2 On Jul 1, 2005, at 12:06 AM, Gabriel Dos Reis wrote: > > There are of course coner and pathological cases, but I don't think we > should worry too much about missing them. Let's first cover the > structured loops, and address the contorsed ones later if they become > really important. And I just submitted a patch for one of those corner/pathological cases and it actually does improve code, how much I don't know because I don't have access to any benchmark to test on. If someone wants to test it, they will most likely find it, it does in fact improve code. Also knowing in let say fold if the variable is a loop index or not is actually not trivial. Another testcase where we will fail out at if we take the view you want to take is: int f(int i) { return (i - 1) > i; } Which is always false if overflow is undefined and not considered wrapping and this shows up in fortran code even though the person did not write it out explicitly: SUBROUTINE d ( a, b,n) IMPLICIT NONE INTEGER :: n REAL,DIMENSION(n) :: a REAL,DIMENSION(n) :: b b(n-2:n) = sqrt(a(n-2:n)) END SUBROUTINE d And this is now done in two different places, fold and simplify-rtx (even though fold does not catch the fortran one as we need a tree combiner for that). And yes I actually reduced that testcase from real fortran code (I forgot which one right now). -- Pinski