Visual Studio 2005 build fails on IEEE754ExceptionsPlugin.cpp

[BillDenton]

...\cpputest\src\CppUTestExt\IEEE754ExceptionsPlugin.cpp(34) : fatal error C1083: Cannot open include file: 'fenv.h': No such file or directory

This is the latest code pulled today. Could you fix this as soon as possible. Note: we also compile with 2013 for some projects, but I haven't test that yet.

[Andne]

Unfortunately, VS2005 is not available on Appveyor, so that build doesn't get checked normally. The project files do get checked since the VS2008 build uses them, just the VS2008 (VC8.0) compiler never gets run.

Actually, looks like the IEE754 files never got added to any of the Visual Studio projects. With a bit of trial and error, I've narrowed down the version fenv.h was added in to 2013. I'll submit a pull request containing the various changes to update the project files and build this logic when possible.

[BillDenton]

Any update? Thanks.

[arstrube]

@BillDenton do you actually need the plugin? Or just want to compile? If it is the first, I'm afraid this is not a trivial matter, because the availability of fenv.h is essential to the plugin. If the latter, just remove the plugin and its associated tests from your project.

@Andne if they were never added, how come they are part of the VS2005 build? I think the best option would be to remove them for now. Does VC support checking the IEEE754 floating point flags in any form at all? If so, as of which version?

@basvodde would it be okay with you if we omit the plugin for older version of Ms VC?

[basvodde]

@arstrube Fine. Also, the plugin fails on my Mac. One test :) should_not_fail_again_when_test_has_already_failed. But only on some builds.

[BillDenton]

I'm updating our internal copy of CppUTest the latest version so we have some of the newer macros. So I just need it to compile. I don't think we have used this plugin has I don't think it was in release 3.7.2 so we can't have used it. If it can't be supported in 2005, then just remove it from the build.

[Andne]

@BillDenton What do you use to run the build? Are you using the Visual Studio solution or CMake?

@arstrube Looks like it supports fenv.h as of 2015, but there's a test failure then. I have the float exception logic suppressed in all other versions, just introduced a bad comment that broke everything else. Excluding the files from the solution works, but not if someone is using cmake I suspect and we'd have to always remember why they're excluded.

[arstrube]

@basvodde I knew I would regret making this part of CppUTestExt, rather than keeping it as a standalone plugin....... :-(

[basvodde]

@arstrube I don't :)

[BillDenton]

It is built from within our build system that uses scons. It builds all the .cpp files in src/CppUTest and src/CppUTestExt. We use 2005 and 2013, but I've only tested 2005 so far. It needs to work for both of these.

[Andne]

PR #948 is merged now, so VS 2005 should build and execute tests fine. VS 2013 builds but it actually tries to test the plugin, so there's a couple failures there. The failures are only in the IEEE 754 exception flag logic, so unless you're trying to use it, I doubt you'll see them in typical project usage.

[arstrube]

@Andne we aren't going to leave the failing tests as a permanent feature though, are we?

[Andne]

No, we need to fix it, I'm just waiting to see what @basvodde thinks about your proposals on the pull request. I don't know why the flags work differently, short term it may just be best to disable the fenv tests completely like Watcom does. I've opened issue #954 to track these test failures and how to resolve them.

@BillDenton Can you please pull the latest code and verify that it works for you now?

[arstrube]

Msvc doesn't pick up FE_INVALID. That's basically its only fault. I think it's an understandable one, because I have a sneaking suspicion that the code in functions like sqrt() sets it "manually"; I don't think the processor ever sets it, which is probably why it can't be generated by any simple arithmetic operation.

[BillDenton]

I've imported the latest code (380450d) and built with both 2005 and 2013. All successfully compiled and our unit tests passed. We were previously using release 3.7.2.
As far as I'm concerned this issue is closed. Would you like me to close it, or is it useful to keep open to discuss the remaining issues?

[Andne]

I opened a different issue to track the FE_INVALID test, so my vote is that this issue can be closed.

[basvodde]

@Andne Will do. Could you or some other Visual C++ person fix the project files and add one file?