Re: amd64 arch and optimization flags?
On Sat, 08 Feb 2014 04:01:53 +0100, Vincent Lefevre wrote:
> 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).
Thanks. I was also pointed to the Kahan summation algorithm that also
would fail with this option set.
In summary, attempting to use rounding errors is fragile with this option
set. Or in other words, rounding errors cease to be reliable. It would
seem in most audio processing algorithms the rounding errors are
irrelevant, given that no complaints have been received by the use of
this flag. The closest I've seen to caring about such things in the code
is rounding denormal numbers to zero.
>
> Be careful with audio processing software, if the audio files can come
> from a remote source.
It would be a rare audio processing suite that didn't handle user-
provided audio files ;)
--
Saludos,
Felipe Sateler
Reply to: