Has anyone noticed -ffast-math (gcc) fights against NaN's?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Has anyone noticed -ffast-math (gcc) fights against NaN's?

Asko Kauppi

I've been revising the LNUM patch (more of that later) and spend  
several hours today trying to understand what exactly -ffast-math does  
with regard to NaN's (not-a-numbers).

Basically, it does not seem to know them. It gives nan==nan and other  
no-can-dos that I regard as Completely Evil as to Lua compatibility.

What I'd ask the list is:

- are you using '-ffast-math' with Lua and gcc?
- have you noticed the inconsistent behaviour of NaN's?
- does it matter to you?

Greetings,   -asko


Reply | Threaded
Open this post in threaded view
|

Re: Has anyone noticed -ffast-math (gcc) fights against NaN's?

Taj Khattra
> I've been revising the LNUM patch (more of that later) and spend several
> hours today trying to understand what exactly -ffast-math does with regard
> to NaN's (not-a-numbers).

from the gcc docs:

`-ffast-math'
     Sets `-fno-math-errno', `-funsafe-math-optimizations',
     `-fno-trapping-math', `-ffinite-math-only', `-fno-rounding-math'
     and `-fno-signaling-nans'.

     This option causes the preprocessor macro `__FAST_MATH__' to be
     defined.

     This option should never be turned on by any `-O' option since it
     can result in incorrect output for programs which depend on an
     exact implementation of IEEE or ISO rules/specifications for math
     functions.

`-ffinite-math-only'
     Allow optimizations for floating-point arithmetic that assume that
     arguments and results are not NaNs or +-Infs.

     This option should never be turned on by any `-O' option since it
     can result in incorrect output for programs which depend on an
     exact implementation of IEEE or ISO rules/specifications.

     The default is `-fno-finite-math-only'.
Reply | Threaded
Open this post in threaded view
|

Re: Has anyone noticed -ffast-math (gcc) fights against NaN's?

Miles Bader-2
In reply to this post by Asko Kauppi
Asko Kauppi <[hidden email]> writes:
> I've been revising the LNUM patch (more of that later) and spend several
> hours today trying to understand what exactly -ffast-math does  with
> regard to NaN's (not-a-numbers).
>
> Basically, it does not seem to know them. It gives nan==nan and other
> no-can-dos that I regard as Completely Evil as to Lua compatibility.

There's a list of what exactly -ffast-math does in the gcc manual (see
Taj Khattra's followup for a quote), but I just wanted to note that you
can tune it by following the -ffast-math option with finer-grained
options that reverse parts of its effect.

E.g., in my proggie, I use:

   -ffast-math -fno-finite-math-only -ftrapping-math -fno-associative-math

"-fno-finite-math-only" and "-ftrapping-math" reverse some of the usual
effect of -ffast-math (-fno-associative-math is just to silence a
warning, as -ftrapping-math automatically implies that anyway).

-Miles

--
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

Reply | Threaded
Open this post in threaded view
|

Of course -ffast-math fights against NaNs

Asko Kauppi

After sending the message I realised how lame it was.  Sorry.

The interesting part is, how are people actually using -ffast-math  
with connection to Lua. And can a Lua that has been stripped of proper  
nan and inf functionality still even be called Lua?
Also, with -ffast-math, Lua code still expects certain behaviour (via  
luai_numisnan macro) instead of disabling all code paths having to do  
with nans.

-asko



Miles Bader kirjoitti 8.4.2009 kello 1:08:

> Asko Kauppi <[hidden email]> writes:
>> I've been revising the LNUM patch (more of that later) and spend  
>> several
>> hours today trying to understand what exactly -ffast-math does  with
>> regard to NaN's (not-a-numbers).
>>
>> Basically, it does not seem to know them. It gives nan==nan and other
>> no-can-dos that I regard as Completely Evil as to Lua compatibility.
>
> There's a list of what exactly -ffast-math does in the gcc manual (see
> Taj Khattra's followup for a quote), but I just wanted to note that  
> you
> can tune it by following the -ffast-math option with finer-grained
> options that reverse parts of its effect.
>
> E.g., in my proggie, I use:
>
>   -ffast-math -fno-finite-math-only -ftrapping-math -fno-associative-
> math
>
> "-fno-finite-math-only" and "-ftrapping-math" reverse some of the  
> usual
> effect of -ffast-math (-fno-associative-math is just to silence a
> warning, as -ftrapping-math automatically implies that anyway).
>
> -Miles
>
> --
> o The existentialist, not having a pillow, goes everywhere with the  
> book by
>  Sullivan, _I am going to spit on your graves_.
>

Reply | Threaded
Open this post in threaded view
|

Re: Of course -ffast-math fights against NaNs

Luiz Henrique de Figueiredo
> And can a Lua that has been stripped of proper nan and inf functionality
> still even be called Lua? Also, with -ffast-math, Lua code still expects
> certain behaviour (via luai_numisnan macro) instead of disabling all code
> paths having to do with nans.

The reference manual does not mention nan or inf, so, yes, it'd be Lua still.
The implementation does make a small concession to the existence of nan, but
if luai_numisnan always returns false the only consequence is that table
entries with nan keys will be inaccesible and will break next...

Here's a session with a patched Lua that ignores nan:

> k=math.sqrt(-1) print(k)
nan
>
> a={}
> a[k]=23 print(a[k])
nil
> a[k]=45 print(a[k])
nil
>
> for k,v in pairs(a) do print(k,v) end
invalid key to 'next'
stack traceback:
        [C]: in function '(for generator)'
        stdin:1: in main chunk
        [C]: ?
nan 23
>
Reply | Threaded
Open this post in threaded view
|

Re: Of course -ffast-math fights against NaNs

Miles Bader-2
In reply to this post by Asko Kauppi
Asko Kauppi <[hidden email]> writes:
> The interesting part is, how are people actually using -ffast-math with
> connection to Lua. And can a Lua that has been stripped of proper  nan
> and inf functionality still even be called Lua?

I don't see why not; Lua doesn't seem to make many guarantees about the
behavior of numbers.  Lua is very often used in fairly specific
contexts, and it's quite reasonable for an app writer to decide that
their app does not need full IEEE floating-point functionality.

-Miles

--
Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven
lies about us.' The world begins lying about us pretty soon afterward.