From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4487 invoked by alias); 5 Nov 2008 18:37:35 -0000 Received: (qmail 4416 invoked by uid 22791); 5 Nov 2008 18:37:35 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.45.13) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 05 Nov 2008 18:36:49 +0000 Received: from spaceape14.eur.corp.google.com (spaceape14.eur.corp.google.com [172.28.16.148]) by smtp-out.google.com with ESMTP id mA5Iaj7K029916; Wed, 5 Nov 2008 10:36:46 -0800 Received: from localhost.localdomain.google.com (dhcp-172-22-125-203.corp.google.com [172.22.125.203]) (authenticated bits=0) by spaceape14.eur.corp.google.com with ESMTP id mA5IafSI014791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Nov 2008 10:36:43 -0800 To: "Joseph S. Myers" Cc: gcc-patches@gcc.gnu.org Subject: Re: [4.5 C] C99-conforming excess precision (fix PR 323 for C) References: From: Ian Lance Taylor Date: Wed, 05 Nov 2008 18:37:00 -0000 In-Reply-To: (Joseph S. Myers's message of "Wed\, 5 Nov 2008 17\:23\:04 +0000 \(UTC\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg00184.txt.bz2 "Joseph S. Myers" writes: > 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. My personal preference would be for the option to become a sorry() for languages which do not support it, when used on a processor where it ought to make a difference. > 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. I agree. Ian