[cfe-dev] Clang-Cl - Representation of NAN

[Gaier, Bjoern via cfe-dev]

Thank you :D
At least I understood that now better ;D

-----Original Message-----
From: Bruce Hoult <brucehoult at sifive.com>
Sent: Dienstag, 5. Februar 2019 12:23
To: Gaier, Bjoern <Bjoern.Gaier at horiba.com>
Cc: cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] Clang-Cl - Representation of NAN

There are 2^53 - 2 different versions of NaN in IEEE double precision.
Correct software or hardware must accept any of them.

(the missing 2 are +/- infinity)

On Tue, Feb 5, 2019 at 3:17 AM Gaier, Bjoern <Bjoern.Gaier at horiba.com> wrote:
>
> We found a bug in our code - but I still wonder why Clang does generate two different versions of NaN.
> (See my other mail for further information)
>
> -----Original Message-----
> From: Bruce Hoult <brucehoult at sifive.com>
> Sent: Dienstag, 5. Februar 2019 12:12
> To: Gaier, Bjoern <Bjoern.Gaier at horiba.com>
> Cc: cfe-dev at lists.llvm.org
> Subject: Re: [cfe-dev] Clang-Cl - Representation of NAN
>
> That's a weird way to do it :-) But it should return NumberFormatInfo.NanSymbol from System.Globalization, which by default is "NaN" (though it has a setter!).
>
> It is doesn't, then that's a bug in double.toString() and you should take that up with Microsoft.
>
> On Tue, Feb 5, 2019 at 2:02 AM Gaier, Bjoern <Bjoern.Gaier at horiba.com> wrote:
> >
> > Hey Bruce,
> >
> > Seems like we are not using 'double.Nan' but foo.toString and then locating there term "nan".
> >
> > -----Original Message-----
> > From: Bruce Hoult <brucehoult at sifive.com>
> > Sent: Dienstag, 5. Februar 2019 10:19
> > To: Gaier, Bjoern <Bjoern.Gaier at horiba.com>
> > Cc: cfe-dev at lists.llvm.org
> > Subject: Re: [cfe-dev] Clang-Cl - Representation of NAN
> >
> > C# can handle NaN correctly. It is important NOT to do "if (foo === double.Nan)" but instead "if(double.IsNan(foo))". C# code that compares with double.NaN is simply buggy.
> >
> > Arithmetic should work correctly in any case.
> >
> > On Tue, Feb 5, 2019 at 12:29 AM Gaier, Bjoern via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> > >
> > > Hello everyone,
> > >
> > >
> > >
> > > we are currently using clang-cl (build with LLVM7) in our project, which previously used the MSVC2017 compiler. We noticed a major difference with the representation of the NAN value.
> > >
> > > Clang generates 0x7FF8000000000000 for an NAN
> > >
> > > MSVC  generates 0xFFF8000000000000 for an NAN
> > >
> > >
> > >
> > > This difference leads to problems with C#, because it interacts with our C++ code and 'misses' the NAN.
> > >
> > >
> > >
> > > Is there a way to change the representation of the NAN via a compiler flag?
> > >
> > > Could we also change the source code of clang to force this representation of NAL? Or is this to much effort for a workaround?
> > >
> > >
> > >
> > > Kind greetings
> > >
> > > Björn
> > >
> > > Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB
> > > 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr.
> > > Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi
> > > Fukushima. Junichi Tajika
> > > _______________________________________________
> > > cfe-dev mailing list
> > > cfe-dev at lists.llvm.org
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
> > Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> > USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr.
> > Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi
> > Fukushima. Junichi Tajika
> Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816,
> USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr.
> Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi
> Fukushima. Junichi Tajika
Als GmbH eingetragen im Handelsregister Bad Homburg v.d.H. HRB 9816, USt.ID-Nr. DE 114 165 789 Geschäftsführer: Dr. Hiroshi Nakamura, Dr. Robert Plank, Markus Bode, Heiko Lampert, Takashi Nagano, Takeshi Fukushima. Junichi Tajika