Always false float comparisons

[Walter Bright via Digitalmars-d]

On 5/18/2016 2:54 AM, Ethan Watson wrote:
> On Wednesday, 18 May 2016 at 08:55:03 UTC, Walter Bright wrote:
>> MSVC doesn't appear to have a switch that does what you ask for
>
> I'm still not entirely sure what the /fp switch does for x64 builds. The
> documentation is not clear in the slightest and I haven't been able to find any
> concrete information. As near as I can tell it has no effect as the original
> behaviour was tied to how it handles the x87 control words. But it might also be
> possible that the SSE instructions emitted can differ depending on what
> operation you're trying to do. I have not dug deep to see exactly how the code
> gen differs. I can take a guess that /fp:precise was responsible for promoting
> my float to a double to call CRT functions, but I have not tested that so that's
> purely theoretical at the moment.
>
> Of course, while this conversation has mostly been for compile time constant
> folding, the example of passing a value from the EE and treating it as a
> constant in the VU is still analagous to calculating a value at compile time in
> D at higher precision than the instruction set the runtime code is compiled to
> work with.
>
> /arch:sse2 is the default with MSVC x64 builds (Xbox One defaults to /arch:avx),
> and it sounds like the DMD has defaulted to sse2 for a long time. The exception
> being the compile time behaviour. That compile time behaviour conforming to the
> the runtime behaviour is an option I want, with the default being whatever is
> decided in here. Executing code at compile time at a higher precision than what
> SSE dictates is effectively undesired behaviour for our use cases.
>
> And in cases where we compile code for another architecture on x64 (let's say
> ARM code with NEON instructions, as it's the most common case thanks to iOS
> development) then it would be forced to fallback to the default. Fine for most
> use cases as well. It would be up to the user to compile their ARM code on an
> ARM processor to get the code execution match if they need it.


Again, even if the precision matches, the rounding will NOT match, and you will 
get different results randomly dependent on the exact operand values.

If those differences matter, then you'll randomly be up all night debugging it. 
If you're willing to try the approach I mentioned, it'll cost you a bit more 
time up front, but may save a lot of agony later.