Clang-Cl - Representation of NAN

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

Clang-Cl - Representation of NAN

David Blaikie via cfe-dev

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
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang-Cl - Representation of NAN

David Blaikie via cfe-dev
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
<[hidden email]> 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
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang-Cl - Representation of NAN

David Blaikie via cfe-dev
Hey Bruce,

Seems like we are not using 'double.Nan' but foo.toString and then locating there term "nan".

-----Original Message-----
From: Bruce Hoult <[hidden email]>
Sent: Dienstag, 5. Februar 2019 10:19
To: Gaier, Bjoern <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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
> [hidden email]
> 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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang-Cl - Representation of NAN

David Blaikie via cfe-dev
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 <[hidden email]> 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 <[hidden email]>
> Sent: Dienstag, 5. Februar 2019 10:19
> To: Gaier, Bjoern <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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
> > [hidden email]
> > 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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang-Cl - Representation of NAN

David Blaikie via cfe-dev
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 <[hidden email]>
Sent: Dienstag, 5. Februar 2019 12:12
To: Gaier, Bjoern <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
> Sent: Dienstag, 5. Februar 2019 10:19
> To: Gaier, Bjoern <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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
> > [hidden email]
> > 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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang-Cl - Representation of NAN

David Blaikie via cfe-dev
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 <[hidden email]> 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 <[hidden email]>
> Sent: Dienstag, 5. Februar 2019 12:12
> To: Gaier, Bjoern <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: Dienstag, 5. Februar 2019 10:19
> > To: Gaier, Bjoern <[hidden email]>
> > Cc: [hidden email]
> > 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 <[hidden email]> 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
> > > [hidden email]
> > > 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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Clang-Cl - Representation of NAN

David Blaikie via cfe-dev
Thank you :D
At least I understood that now better ;D

-----Original Message-----
From: Bruce Hoult <[hidden email]>
Sent: Dienstag, 5. Februar 2019 12:23
To: Gaier, Bjoern <[hidden email]>
Cc: [hidden email]
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 <[hidden email]> 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 <[hidden email]>
> Sent: Dienstag, 5. Februar 2019 12:12
> To: Gaier, Bjoern <[hidden email]>
> Cc: [hidden email]
> 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 <[hidden email]> 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 <[hidden email]>
> > Sent: Dienstag, 5. Februar 2019 10:19
> > To: Gaier, Bjoern <[hidden email]>
> > Cc: [hidden email]
> > 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 <[hidden email]> 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
> > > [hidden email]
> > > 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
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev