From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-93350-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 12274 invoked by alias); 25 Mar 2004 00:02:54 -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 12259 invoked from network); 25 Mar 2004 00:02:50 -0000
Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186)
  by sources.redhat.com with SMTP; 25 Mar 2004 00:02:50 -0000
Received: from uniton.integrable-solutions.net (localhost [127.0.0.1])
	by uniton.integrable-solutions.net (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id i2ONpA9b011192;
	Thu, 25 Mar 2004 00:51:10 +0100
Received: (from gdr@localhost)
	by uniton.integrable-solutions.net (8.12.3/8.12.3/Submit) id i2ONp9PB011191;
	Thu, 25 Mar 2004 00:51:09 +0100
X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f
To: Toon Moene <toon@moene.indiv.nluug.nl>
Cc: Joe Buck <Joe.Buck@synopsys.COM>, Bradley Lucier <lucier@math.purdue.edu>,
   roger@eyesopen.com, gcc@gcc.gnu.org, abraham@dina.kvl.dk,
   gcc-patches@gcc.gnu.org, laurent@guerby.net, fjahanian@apple.com
Subject: Re: GCC beaten by ICC in stupid trig test!
References: <13661448-7DC0-11D8-817F-000A958F150A@math.purdue.edu>
	<20040324105146.A1279@synopsys.com>
	<EDB6EC7E-7DC4-11D8-817F-000A958F150A@math.purdue.edu>
	<20040324110433.A2050@synopsys.com>
	<4061F6EF.3090803@moene.indiv.nluug.nl>
From: Gabriel Dos Reis <gdr@integrable-solutions.net>
In-Reply-To: <4061F6EF.3090803@moene.indiv.nluug.nl>
Organization: Integrable Solutions
Date: Thu, 25 Mar 2004 05:36:00 -0000
Message-ID: <m3brml7qj6.fsf@uniton.integrable-solutions.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2004-03/txt/msg01431.txt.bz2

Toon Moene <toon@moene.indiv.nluug.nl> writes:

| Joe Buck wrote:
| 
| > No.  Why would we need such a thing?  If the user does not care about
| > order of evaluation, the user can write a+b+c .  As someone said, right
| > now we can't tell the difference between a+b+c; if we turn it into GIMPLE
| > and make t1 = a+b; 52 = t1+c; we can't tell if the user initially wrote
| > (a+b)+c or a+b+c.
| 
| This is true as far as Fortran is concerned (I cannot speak for other
| languages).
| 
| A+B+C means that the compiler could either evaluate (A+B)+C or A+(B+C)
| or (A+C)+B.

The C++ standard clearly says that re-association is permitted only if
the re-associated expression gives the same result as the original.
So A+B+C really is (A+B)+C.

-- Gaby