[FFmpeg-devel] [PATCH 2/2] configure: Use intel math.h header.

[Reimar Döffinger]

On 10.05.2014, at 19:44, Matt Oliver <protogonoi at gmail.com> wrote:

> On 11 May 2014 03:03, Reimar Döffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
>> On 07.05.2014, at 15:52, Matt Oliver <protogonoi at gmail.com> wrote:
>>> icl when run under msvc12 currently generates incorrect code. This is due
>>> to an issue with msvc12's C99 additions to math.h. Several defines in
>>> msvc's math.h are not compatible with icl and will compile but generate
>>> erroneous results during runtime. An obvious example is that NAN from
>>> math.h evaluates to 0.0 under icl which is clearly not a correct value
>> for
>>> NaN. This cause several errors that completly break FFmpeg.
>>> 
>>> There are several ways to fix this. 1) Force icl's floating point
>>> compliance but negatively impact performance in doing so. 2) Add compiler
>>> specific code into FFmpeg or 3) Have icl use its own native math header
>>> (which can also improve performance).
>> 
>> To be honest I find this quite ridiculous.
>> Almost two years should be enough for Intel to get the standard system
>> headers to work correctly.
>> Or to put it differently: Using ICL starts to sound like a horribly bad
>> idea if it already miscompiles basic system headers, which in turn IMHO
>> raises some questions how many hacks we should accept for it.
> 
> 
> True, Im amazed this hasnt been an issue more often. Im guessing most
> people with icl will use the icl header and the rest just havnt noticed the
> problem. The exact issue is that the msvc headers define NAN as ( INFINITY
> * 0.0 ) which the optimizers in icl just replace with 0. So it will work
> fine if you disable optimization and force floating point compliance but
> this defeats the purpose of an optimizing compiler like icl

No, it really doesn't. Floating-point code is not the only thing in a program and e.g. /fp:precise still allows plenty of (problematic) invalid optimizations.
The problem is that Intel decide to enable by default very dangerous and wrong optimizations.
If you search for the gcc "equivalent" -ffast-math you should find lots of examples.
These optimizations are _dangerous_ and honestly you'd have to be insane to enable them _globally_. Floating-point is problematic enough even if you can rely on compliance.
We do not support/enable it on gcc for good reasons, and I object to supporting it for other compilers just because the vendor though fast is better than safe.
If we want it, make it an option and add -ffast-math for gcc as well. Anything else is just setting people up for wrong benchmarks (by allowing only some compilers to ignore the rules) and other bad surprises.

> Optimizing
> out multiplies by zero is standard procedure by all compilers not just icl

No it isn't. Just try writing a function that multiplies a float value by 0 and look at the generated assembler code.

> Msvc also optimizes
> out multiplies by zero

I'm fairly certain it does not with default options.