[LAD] Is -ffast-math safe for audio?

[Nikita Zlobin]

It's probably gonna be silly question, but after short analysis i don't
see, what could be broken in this demo snippet, when float is standard
single-precision 32bit type.

I omit first case, as optimizing compiler could just optimize it to
just =1; though it could do it in second case too... (as assumed, i did
not try to compile it yet).
But even without underhood tricks - 32bit float has 23/24bit for
significand, thus

In Fri, 23 Nov 2018 14:09:02 +0100
Robin Gareus <robin at gareus.org> wrote:

> On 11/23/2018 01:00 PM, Will Godfrey wrote:
> [...]
> > Thanks for going into this in such detail Robin. I never realised
> > fp stuff could be *quite* so, umm, approximate!  
> 
> Depending on context and the maths, the difference may not matter at
> all, or may be off completely..
> 
>   float a = (1 + 1e20) - 1e20;
>   float b = 1 + 1e20; b -= 1e20;
>   printf ("%f %f\n", a, b);
> 
> Any guesses what this code prints without compiling it? :)
> 
> > I was using O3. Following on from this I found that if I removed
> > either O3 or ffast-math the problem disappeared.  
> 
> OK, so SSE/AVX/compiler-intrinsics are the issue at hand.
> 
> > It's quite possible that I'm over-thinking this as there are
> > actually only a few iterations before the initial figures are
> > re-calculated, but I don't like mysteries :(
> >   
> 
> You could also disable this for a specific function only
> 
> __attribute__((optimize("-fno-fast-math")))
> void different_mysteries_here (float val)
> {
>     ...
> }
> 
> ciao,
> robin
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev at lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev