Visual C++ 2013 floating point broken on first use - by Lewis Pringle

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 808199 Comments
Status Closed Workarounds
Type Bug Repros 4
Opened 11/10/2013 8:34:19 AM
Access Restriction Public


This completely shocked me, and if you think this is too crazy to believe -try it.

It appears that if you have a function which returns a double, and then call it from another procedure - the returned value always becomes '.#IND'.

If you re-run the same procedure - it works fine.

This is NOT an issue with the optimizer - but with the 'debug' mode builds.
Sign in to post a comment.
Posted by Deon [MSFT] on 6/6/2014 at 9:53 AM
Thank you for using Visual Studio and for reporting this bug. We are happy to let you know that this issue has been fixed in Visual Studio 2013 Update 2. If you already have Visual Studio 2013, you can upgrade to Update 2 for free or you can install a trial version from:
Posted by Bruce Dawson on 5/16/2014 at 3:07 PM
Note that this bug is also reported in

Also note that I can confirm that this bug is fixed in VS 2013 Update 2.
Posted by Eric [MSFT] on 1/28/2014 at 2:51 PM
Hi, the fix will be in VSUpdate 2. We have not yet released a date for this release.

_MSC_VER only gives major version numbers. You'll need to use _MSC_FULL_VER if you want to match against a proper release number.

Eric Brumer
Microsoft Visual C++ Team
Posted by Lewis Pringle on 1/25/2014 at 4:15 AM
Your comment says this will be fixed in the next VS Update.

I just installed VS Update 1 (released around 2014-01-20).

Is this fix in that update? If so - how do I detect this from code?
Currently my bug workaround in code reads
#if _MSC_VER == 1800

But the __MSC_VER in this update is unchanged, and the release notes dont mention this (or any other compiler) bug fixes.
Posted by Charles [MSFT] on 1/13/2014 at 11:15 AM
The fix is targeted to be shipped in the next VS Update (Spring). In the meantime, I attached a private file ftol3.obj with the fix (The file might take several minutes or hours to appear).

Sorry for the bug.

Charles Fu
Visual Studio C++ Team.
Posted by Lewis Pringle on 11/26/2013 at 8:12 PM
Nice work analyzing.

I assume this will be fixed in your next VC++ service pack. Can you confirm, and have any idea when that will be?
Posted by Mike Danes on 11/26/2013 at 10:44 AM
Here's how to reproduce the bug without Stroika:

#include <limits>
#include <cstdio>

double foo() {
    return 1.0;

int main()
    for (int i = 0; i < 10; i++) {
        unsigned d = static_cast<unsigned>(std::numeric_limits<double>::max() / 2.0);

        printf("%f\n", foo());

    return 0;

There's a bug in a CRT function (dtoui3) which is used to convert from double to unsigned, it "leaks" a x87 stack register and ends up causing a stack overflow. That's how the fld1 instruction used by foo ends up producing an IND.
Posted by Lewis Pringle on 11/21/2013 at 6:18 PM
I'm baffled by your feedback. I reported the bug because I believe its an MSVC++ bug.

This library in question runs on many platforms, and dozens of compilers. This is the only one with this issue. In fact, this issue doesn't exist with MSVC++ 2k12.

If you give me the source code for your compiler, and pay me to fix it - I will fix the bug. But short of that - reporting a reproducible case is the limit of my contribution. It's up to you to debug and and fix the problem.
Posted by Eric [MSFT] on 11/21/2013 at 1:36 PM
Hi, yes this is very strange. I was trying to narrow down the repro case, and I noticed that it requires the Stroika leak checker to be initialized, otherwise the bug doesn't repro.

As a start, if you open D:\Stroika\CURRENT\Library\Sources\Stroika\Foundation\Memory\LeakChecker.inl and comment out the last line (defining the ModuleData_), rebuild Stroika-Foundation, then run your test again -- it does the right thing.

Since this looks like there's a weird interaction with your code base, I'll let you take a shot at figuring out what is causing it.

If you do find that this is a MSVC++ issue, please reply with a standalone repro that causes the issue.

Eric Brumer
Microsoft Visual C++ Team
Posted by Microsoft on 11/13/2013 at 12:44 AM
Thanks for your response.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Lewis Pringle on 11/12/2013 at 7:24 AM
I just uploaded a zipfile with all that you need to reproduce the problem.

unzip the attachment, and open the project Stroika-test-10-demonstrates-float-bug\Stroika\10\Test.sln

Set a breakpoint on the retunr value in main, and run. Note the value is nan, but look at the code. It should be 1.0.
Posted by Microsoft on 11/11/2013 at 11:23 PM

Sorry for bothering. Is there any update?

It would be greatly appreciated if you could provide us with that information as quickly as possible.

Thank you!
Posted by Microsoft on 11/10/2013 at 11:12 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. In order to fix the issue, we must first reproduce the issue in our labs. We are unable to reproduce the issue with the steps you provided.

Could you please give us a demo project to demonstrate this issue so that we can conduct further research?

Please submit this information to us within 4 business days. We look forward to hearing from you with this information.

Microsoft Visual Studio Connect Support Team
Posted by Microsoft on 11/10/2013 at 8:52 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(