From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10232 invoked by alias); 5 Nov 2008 17:24:06 -0000 Received: (qmail 10199 invoked by uid 22791); 5 Nov 2008 17:24:05 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Nov 2008 17:23:07 +0000 Received: (qmail 24164 invoked from network); 5 Nov 2008 17:23:05 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Nov 2008 17:23:05 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.68) (envelope-from ) id 1Kxm5w-0003mW-0V; Wed, 05 Nov 2008 17:23:04 +0000 Date: Wed, 05 Nov 2008 17:24:00 -0000 From: "Joseph S. Myers" To: Ian Lance Taylor cc: gcc-patches@gcc.gnu.org Subject: Re: [4.5 C] C99-conforming excess precision (fix PR 323 for C) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-11/txt/msg00179.txt.bz2 On Wed, 5 Nov 2008, Ian Lance Taylor wrote: > "Joseph S. Myers" writes: > > > Bootstrapped with no regressions on i686-pc-linux-gnu. Are the > > non-C-front-end parts OK for 4.5? > > This is OK for 4.5. (Note that this is built on the infrastructure from my constant expressions patch , which has changes to builtins.c and cp/typeck.c pending review for 4.5.) > What happens if -fexcess-precision=standard is used with C++? It > seems that the option will be accepted without complaint but that > there may be some cases where it will not work correctly. It might be > better to reject the option until the C++ frontend can be corrected. Yes, the option is quietly ignored for * languages whose front ends do not implement it (i.e. implement some form of predictable semantics for the option that mean GIMPLE arithmetic is not generated for types the back end does not support arithmetic on); * processors with no excess precision issues, and processor configurations such as -mfpmath=sse without such issues (this should in theory work with -mfpmath=sse changing on a per-function basis; at least, the relevant variable setting is done as part of reinitialization); * configurations with options that are expected to give unpredictable excess precision (-mfpmath=sse+387) or to give larger errors than arise with excess precision (-funsafe-math-optimizations). The first could alternatively become an error as you suggest, or could make the option an alias for -ffloat-store for such front ends as the nearest equivalent available. (Such an error or -ffloat-store aliasing would in the simplest implementation apply for all processors including those with no excess precision issues, though the compiler could be made to track whether there is a non-default TARGET_FLT_EVAL_METHOD definition or whether it's known that there will be no excess precision issues in any function.) I do hope people will eventually implement suitable predictable semantics for other front ends so -ffloat-store can end up as an alias for the new option, flag_float_store checks in optimizers can go away and the PR can be closed. -- Joseph S. Myers joseph@codesourcery.com