Floating point performance issue

Vincent Lefevre vincent+gcc@vinc17.org
Tue Dec 20 15:05:00 GMT 2011

On 2011-12-20 14:57:16 +0100, David Brown wrote:
> On 20/12/2011 14:43, Vincent Lefevre wrote:
> >I disagree: the operations could be written in an order to avoid some
> >inaccuracies (such as huge cancellations) or to emulate more precision
> >(e.g. via Veltkamp's splitting) or to control the rounding (see some
> >rint() implementation http://sourceware.org/bugzilla/show_bug.cgi?id=602
> >for instance). On such code, unsafe optimizations could yield problems.
> I guess that's why it's an option - then we can choose.

Really, it should have never been an option since it may produce
incorrect code. Such kinds of optimization should have only been
enabled via pragmas, and only in a well-documented manner so that
the developer can know how this code could be transformed (and
only the developer should be allowed to enable such optimizations).

> I would still say that most floating point code does not need such
> control, and that situations where it matters are rather
> specialised.

I think that if this were true, there would have never been an
IEEE 754 standard.

> But that's just my unfounded opinion - judging from your signature
> you /do/ need such tight control in your work, while I've only
> learned today that "-ffast-math" has effects other than possibly
> changing the generated code.

This is on a different matter, but you can look at


(see also the huge number of duplicates). Many people complain
about floating-point when it gives "unexpected" results...

Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

More information about the Gcc-help mailing list