[cfe-dev] Clang-Cl - Representation of NAN; Code to reproduce

[Gaier, Bjoern 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 <andrew.kaylor at intel.com>
Sent: Dienstag, 5. Februar 2019 21:54
To: Marcus Johnson <bumblebritches57 at gmail.com>
Cc: Gaier, Bjoern <Bjoern.Gaier at horiba.com>; cfe-dev at lists.llvm.org
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 <bumblebritches57 at gmail.com<mailto:bumblebritches57 at gmail.com>>
Sent: Tuesday, February 05, 2019 12:24 PM
To: Kaylor, Andrew <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>
Cc: Gaier, Bjoern <Bjoern.Gaier at horiba.com<mailto:Bjoern.Gaier at horiba.com>>; cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190206/b00da03f/attachment.html>