This is the mail archive of the
mailing list for the GCC project.
Re: Draft "Unsafe fp optimizations" project description.
- To: <dewar at gnat dot com>, <toon at moene dot indiv dot nluug dot nl>
- Subject: Re: Draft "Unsafe fp optimizations" project description.
- From: "Tim Prince" <tprince at computer dot org>
- Date: Sun, 5 Aug 2001 08:40:52 -0700
- Cc: <gcc at gcc dot gnu dot org>, <lucier at math dot purdue dot edu>
- References: <20010805114016.9607EF2B53@nile.gnat.com>
----- Original Message -----
To: <firstname.lastname@example.org>; <email@example.com>;
Cc: <firstname.lastname@example.org>; <email@example.com>
Sent: Sunday, August 05, 2001 4:40 AM
Subject: Re: Draft "Unsafe fp optimizations" project
> <<One of my original reasons for provoking this discussion
was my hope of
> dealing with the need to conform with C and Fortran
> require re-association to be preventable by parentheses,
> optimizations such as -ffast-math are in effect. According
> No, that's wrong, there is nothing to prevent -ffast-math
> parentheses in Fortran. The Fortran standard has nothing to
> compiler switches that deliberately provide other than
> and such switches are perfectly reasonable.
> Remember that in Fortran, one might use parens to override
> or simply for documentation purposes. The fact that these
> desired optimizations might be annoying in some
circumstances, and if
> you take the "anything goes, speed all important" viewpoint
> -ffast-math, then it would be entirely reasonable to have
> override the effect of parens.
> Indeed that's what makes sense to me in Fortran. After all
it is allowable
> by default in the absence of parens to do some of the
> we have been discussing here, so I would think
that -ffast-math in
> Fortran would be about forcing additional freedom beyond
> by the standard.
> A Fortran expert writes parens where needed, and is not
allowed to be
> surprised by transformations in the absence of parens (of
> still discussion there, but the use of parens is in any case
> to ensure canonical evaluation semantics).
At present, -ffast-math has to be invoked in order to get many
of the optimizations expected in Fortran. It should be
possible to select between the optimizations which are
somewhat risky and not permitted by IEEE, but expected
according to Fortran, and those which may exceed the bounds
set by Fortran. As Toon mentioned, placing too many
additional transformations under -ffast-math without options
to shut them off may prevent the use of -ffast-math in
situations where it is useful now. I face this problem daily
with commercial compilers, more so with C++, where the choices
are between very little optimization with insufficient
performance, and a broken application.