From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-60833-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 5533 invoked by alias); 1 Oct 2002 21:14:42 -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 5518 invoked from network); 1 Oct 2002 21:14:39 -0000
Received: from unknown (HELO kiruna.synopsys.com) (204.176.20.18)
  by sources.redhat.com with SMTP; 1 Oct 2002 21:14:39 -0000
Received: from crone.synopsys.com (crone.synopsys.com [146.225.7.23])
	by kiruna.synopsys.com (Postfix) with ESMTP
	id 7B251F4A2; Tue,  1 Oct 2002 14:14:39 -0700 (PDT)
Received: from atrus.synopsys.com (localhost [127.0.0.1])
	by crone.synopsys.com (8.9.3+Sun/8.9.1) with ESMTP id OAA08292;
	Tue, 1 Oct 2002 14:14:16 -0700 (PDT)
From: Joe Buck <Joe.Buck@synopsys.com>
Received: (from jbuck@localhost)
	by atrus.synopsys.com (8.9.3+Sun/8.9.1) id OAA16417;
	Tue, 1 Oct 2002 14:14:37 -0700 (PDT)
Message-Id: <200210012114.OAA16417@atrus.synopsys.com>
Subject: Re: module level flags
To: dewar@gnat.com (Robert Dewar)
Date: Tue, 01 Oct 2002 14:54:00 -0000
Cc: Joe.Buck@synopsys.COM, bkorb@pacbell.net, aoliva@redhat.com,
	dewar@gnat.com, gcc@gcc.gnu.org, zack@codesourcery.com
In-Reply-To: <20021001203334.7798EF28F4@nile.gnat.com> from "Robert Dewar" at Oct 01, 2002 04:33:34 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-SW-Source: 2002-10/txt/msg00057.txt.bz2


> <<It's not a matter of not wanting to learn the rules.  It's a matter
> of dealing with massive amounts of legacy code written before the
> aliasing optimizations were devised.  This is a change in the C
> language that is only a very few years old.  Silently biting people
> isn't the way to do it.
> >>

This is incorrect: similar language is in the C89 standard (though someone
quoted you the version in C99).  It's 13 years old.

> Neither is deoptimizing the code in a manner that results in 
> not taking advantage of this feature of the standard.
> 
> -fno-strict-aliasing is precicsely meant to deal with ":massive
> amounts of legacy code written before the aliasing o[ptimziations were devised".
> Why should you be reluctant to use it.
> 
> Mind you, the code we are talking about here is not "massive amounts of legacy
> code written before ...", but jsut one program with an obvious bug
> that is easily fixed!

Can any folks from Red Hat or elsewhere comment on how many violations
they found when they first switched to compilers that implement
strict-aliasing by default?