import std.math;
import std.stdio;
void main() {
writeln(PI);
}
With latest GIT HEAD prints
1.4488e+19
Comment #1 by dlang-bugzilla — 2015-02-07T10:43:37Z
I can't reproduce this...
Comment #2 by temtaime — 2015-02-07T12:44:30Z
The bug exists only on Windows when dmd is built with /GL, /LTCG compiler optimization options.
2.066 compiles and runs successfully with these options.
Comment #3 by blah38621 — 2015-02-07T20:18:38Z
Which version of MSVC? I use a 64-bit DMD compiled by MSVC 2010 with link-time code gen (/LTCG) and whole program optimization (/GL), and have no issues here. Is it possible that you've changed the floating point model in your build to something other than precise (/fp:precise)?
Comment #4 by temtaime — 2015-02-08T14:56:20Z
I'm using MSVC 2013 with /O2 /GL /Gw /fp:fast.
Can /fp:fast have an effect on DMD ? I'll with /GL and without /fp:fast, okay.
Comment #5 by dlang-bugzilla — 2015-02-08T14:57:44Z
The VS solution included with DMD has a "Release" target, any reason you're not using that?
Comment #6 by code — 2015-02-11T17:55:07Z
Any insight on why LTO mess this up?
Comment #7 by bugzilla — 2015-02-16T09:35:19Z
(In reply to Temtaime from comment #4)
> I'm using MSVC 2013 with /O2 /GL /Gw /fp:fast.
>
> Can /fp:fast have an effect on DMD ? I'll with /GL and without /fp:fast,
> okay.
According to Microsoft documentation, /fp:fast will:
"Creates the fastest code in most cases by relaxing the rules for optimizing floating-point operations. This enables the compiler to optimize floating-point code for speed at the expense of accuracy and correctness."
-- https://msdn.microsoft.com/en-us/library/e7s85ffb.aspx
I interpret that as meaning "insert random bugs in floating point code".
DMD is not designed to work with that, and was certainly never tested with that. I'm going to mark this as WONTFIX. The only supported build options are the ones in the VS solution included with DMD.