clipka <ano### [at] anonymousorg> wrote:
> Am 06.07.2014 13:58, schrieb Thorsten Froehlich:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 02.07.2014 18:44, schrieb Le_Forgeron:
> >>
> >>> Rendering benchmark gives the attached pictures (the icpc seems ok,
> >>> within usual time, but gcc is bogus and too fast, far too fast)
> >>
> >> I finally found out what's going on here.
> >>
> >> The implementation of adaptive area lights uses an N*M cache for
> >> "lightlet" data it has already computed. Previously, yet-uncomputed data
> >> was flagged by setting the respective colour's red channel to -1. I had
> >> changed this to use a NaN ("Not-a-Number") value instead, to avoid
> >> problems when a user deliberately sets a light source's colour to
> >> negative red.
> >>
> >> Now of course this NaN value has to be tested for; according to IEEE
> >> standard, a NaN value has the property that it is non-equal to anything,
> >> even itself. So I wrote the test: "if (red != red)...".
> >>
> >> Well, it turns out that the g++ compiler optimizes this comparison away
> >> when in "-ffast_math" mode.
> >
> > Use std::isnan - it works because IEEE 754 and C++ floats are not exactly the
> > same, and for most practical purposes NaNs will have a valid and identical
> > storage in memory. Be aware that NaNs and Infinites may raise exceptions
> > regardless though.
>
> std::isnan() is not a universal solution either, as it's not C++(03)
> standard; for instance, Microsoft Visual C++ doesn't have it (it has an
> _isnan() function instead). And I haven't tested whether it actually
> solves the problem - according to the gcc documentation, -ffast_math
> means that the compiler doesn't know anything about infinities and NaNs
> at all, and the std::isnan function might just as well always return false.
>
> So while it is now clear what's happening, this is not solved yet, so I
> have my work cut out for me tonight.

Its in C99 and C++11, but indeed will not work with fast math on for the
respective function. Other than disabling fast math for said function, using a
less likely magic value like HUGE_VALF or a separate store for the flag are all
the portable ways left.

Post a reply to this message