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 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 (see also the huge number of duplicates). Many people complain about floating-point when it gives "unexpected" results... -- Vincent Lefèvre <vincent@xxxxxxxxxx> - 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)