Clang-Cl - Representation of NAN; Code to reproduce

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

Clang-Cl - Representation of NAN; Code to reproduce

Дилян Палаузов via cfe-dev

I discovered something new, that is interesting:

When I compile:

 

volatile const double result = 0.0/0.0;

This will result in "0x7FF8000000000000"

 

But:

volatile const double bla      = 0.0;

volatile const double result = 0.0/bla;

Will result in "0xFFF8000000000000"

 

Both compiled with Clang of course!

 

 

From: cfe-dev <[hidden email]> On Behalf Of Gaier, Bjoern via cfe-dev
Sent: Dienstag, 5. Februar 2019 09:29
To: [hidden email]
Subject: [cfe-dev] Clang-Cl - Representation of NAN

 

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

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; Code to reproduce

Дилян Палаузов via cfe-dev

In the first case (0.0/0.0) clang’s constant folder gets rid of the division and replaces it with clang’s default representation of NaN. In the second case (0.0/bla) because you’ve declared ‘bla’ as volatile we actually perform the division, so the NaN in that case comes from the processor.

 

-Andy

 

From: cfe-dev <[hidden email]> On Behalf Of Gaier, Bjoern via cfe-dev
Sent: Tuesday, February 05, 2019 1:33 AM
To: [hidden email]
Subject: [cfe-dev] Clang-Cl - Representation of NAN; Code to reproduce

 

I discovered something new, that is interesting:

When I compile:

 

volatile const double result = 0.0/0.0;

This will result in "0x7FF8000000000000"

 

But:

volatile const double bla      = 0.0;

volatile const double result = 0.0/bla;

Will result in "0xFFF8000000000000"

 

Both compiled with Clang of course!

 

 

From: cfe-dev <[hidden email]> On Behalf Of Gaier, Bjoern via cfe-dev
Sent: Dienstag, 5. Februar 2019 09:29
To: [hidden email]
Subject: [cfe-dev] Clang-Cl - Representation of NAN

 

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

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; Code to reproduce

Дилян Палаузов via cfe-dev
So MSVC's setting the sign bit when it shouldn't, report the bug to them.

_______________________________________________
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; Code to reproduce

Дилян Палаузов via cfe-dev

Actually, it looks like MSVC always does the division. The sign bit doesn’t matter.

 

FWIW, gcc also does the division in the non-volatile 0.0/0.0 case because it is preserving the floating point status flag that gets set by this operation. If you pass -ffast-math or -fno-trapping-math to gcc it will constant fold (to the same value clang uses). I can’t get MSVC to do the constant folding, but I might just not know the right option.

 

It's probably worth mentioning that clang doesn’t guarantee that floating point exception/status flag semantics will be preserved. That’s currently under development.

 

-Andy

 

From: Marcus Johnson <[hidden email]>
Sent: Tuesday, February 05, 2019 12:24 PM
To: Kaylor, Andrew <[hidden email]>
Cc: Gaier, Bjoern <[hidden email]>; [hidden email]
Subject: Re: [cfe-dev] Clang-Cl - Representation of NAN; Code to reproduce

 

So MSVC's setting the sign bit when it shouldn't, report the bug to them.


_______________________________________________
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; Code to reproduce

Дилян Палаузов via cfe-dev

Hello Andy,

 

Thank you for the comparison and the explanation of the effect. I’m still a beginner and I’m always happy to learn something new!

 

I understand now how the different values came to be and why they shouldn’t matter. Thank you all!

 

Kind greetings

Björn

 

From: Kaylor, Andrew <[hidden email]>
Sent: Dienstag, 5. Februar 2019 21:54
To: Marcus Johnson <[hidden email]>
Cc: Gaier, Bjoern <[hidden email]>; [hidden email]
Subject: RE: [cfe-dev] Clang-Cl - Representation of NAN; Code to reproduce

 

Actually, it looks like MSVC always does the division. The sign bit doesn’t matter.

 

FWIW, gcc also does the division in the non-volatile 0.0/0.0 case because it is preserving the floating point status flag that gets set by this operation. If you pass -ffast-math or -fno-trapping-math to gcc it will constant fold (to the same value clang uses). I can’t get MSVC to do the constant folding, but I might just not know the right option.

 

It's probably worth mentioning that clang doesn’t guarantee that floating point exception/status flag semantics will be preserved. That’s currently under development.

 

-Andy

 

From: Marcus Johnson <[hidden email]>
Sent: Tuesday, February 05, 2019 12:24 PM
To: Kaylor, Andrew <[hidden email]>
Cc: Gaier, Bjoern <[hidden email]>; [hidden email]
Subject: Re: [cfe-dev] Clang-Cl - Representation of NAN; Code to reproduce

 

So MSVC's setting the sign bit when it shouldn't, report the bug to them.

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