From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-117143-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 23920 invoked by alias); 12 Jul 2005 16:45:40 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
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 23762 invoked by uid 22791); 12 Jul 2005 16:45:34 -0000
Received: from us02smtp1.synopsys.com (HELO vaxjo.synopsys.com) (198.182.60.75)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 12 Jul 2005 16:45:34 +0000
Received: from crone.synopsys.com (crone.synopsys.com [146.225.7.23])
	by vaxjo.synopsys.com (Postfix) with ESMTP
	id 5AB97DC51; Tue, 12 Jul 2005 09:45:32 -0700 (PDT)
Received: from piper.synopsys.com (localhost [127.0.0.1])
	by crone.synopsys.com (8.9.1/8.9.1) with ESMTP id JAA28428;
	Tue, 12 Jul 2005 09:45:31 -0700 (PDT)
Received: from piper.synopsys.com (localhost [127.0.0.1])
	by piper.synopsys.com (8.12.10/8.12.3) with ESMTP id j6CGjVOe005364;
	Tue, 12 Jul 2005 09:45:31 -0700
Received: (from jbuck@localhost)
	by piper.synopsys.com (8.12.10/8.12.10/Submit) id j6CGjVd6005362;
	Tue, 12 Jul 2005 09:45:31 -0700
Date: Tue, 12 Jul 2005 16:45:00 -0000
From: Joe Buck <Joe.Buck@synopsys.COM>
To: Nicholas Nethercote <njn@cs.utexas.edu>
Cc: gcc@gcc.gnu.org
Subject: Re: Some tests in gcc.c-torture rely on undefined behaviour?
Message-ID: <20050712164531.GA1213@synopsys.com>
References: <Pine.LNX.4.63.0507120914490.23582@charco.cs.utexas.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.63.0507120914490.23582@charco.cs.utexas.edu>
User-Agent: Mutt/1.4.1i
X-SW-Source: 2005-07/txt/msg00507.txt.bz2

On Tue, Jul 12, 2005 at 09:41:22AM -0500, Nicholas Nethercote wrote:
> I've been looking at the gcc.c-torture tests, it seems some of them rely 
> on undefined behaviour.  For example, 920612-1.c looks like this:
> 
>   f(j)int j;{return++j>0;}
>   main(){if(f((~0U)>>1))abort();exit(0);}

Wow.  It appears that it would be legal for a C compiler to optimize f() to

int f(int j) { return 1;}

since the compiler is entitled to assume that overflow does not occur.

Just the same, I don't think we necessarily want to take advantage of
every degree of freedom the standards give us (at least, not by default).

(Oh, crap; I see a massive thread re-emerging).