Re: amd64 arch and optimization flags?
On 2014-02-06 13:44:30 +0000, Felipe Sateler wrote:
> On Thu, 06 Feb 2014 00:47:54 +0100, Julian Taylor wrote:
> > On 06.02.2014 00:39, Jaromír Mikeš wrote:
> >> -ffast-math
> >
> > this is dangerous it changes results, sometimes significantly (e.g. for
> > complex numbers), only use if you don't care about correctness or have
> > verified its still correct.
>
> IME, audio processing software can get away with it. Csound and its 400+
> library of opcodes has been built with this option and I have had no
> complaints yet.
>
> What is dangerous about this options? I see a warning in the gcc docs,
> but how can I know if my program relies "on a precise definition of IEEE
> floating point"?
Some specific floating-point algorithms (in particular those that
"emulate" additional precision by controlling the roundings) will
not work with it.
An example is https://www.vinc17.net/software/sipe.h when using
SIPE_FLOAT (though I haven't tested).
For floating-point algorithms that just assume that operations are
performed with some rounding error but without going further on
IEEE 754 properties and do not use special values (infinities and
signed zeros), -ffast-math may work. But -ffast-math enables
-fassociative-math and -freciprocal-math, which may increase the
expected rounding errors in some cases.
Note also that using -ffast-math may introduce security holes, for
instance if an algorithm that fills an array converges slower with
it, yield a buffer overflow. This is more or less what happened for
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6499
https://bugzilla.mozilla.org/show_bug.cgi?id=358569
(the cause wasn't -ffast-math, but involved reduced accuracy).
Be careful with audio processing software, if the audio files can
come from a remote source.
--
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Reply to: