Issue affects both the current NMake build and the forthcoming CMake build.
Additional symptom: Incorrect binary floating point (BFP) results for selected instructions when compiled on Windows using the NMake build.
The version of SoftFloat-3a headers included with Hyperion unconditionally includes stdbool.h. These headers are one commit back from the headers included in SoftFloat-3a, which make the #include conditional on HAVE_STDBOOL.H. The CMake build for SoftFloat-3a tests for stdbool.h and sets HAVE_STDBOOL.H accordingly. Neither the CMake build for Hercules, the GNU Autotools build, nor the NMake Windows build test for stdbool.h.
The incorrect BFP results occur because the NMake build does not report the presence of stdbool.h on VS2015+ systems, and Hyperion is compiled with a different definition for the type bool (int, defined in softfloat_stdTypes.h or worse, not at all) than SoftFloat (_bool, a char-sized type defined in stdbool.h).
There is no requirement that a c compiler map the type bool to a char.
The types and macros defined in stdbool.h or substituted in softfloat_stdTypes.h are used only within ieee.c or in the interface between ieee.c and Softfloat-3a. Other Hercules headers define TRUE and FALSE as 1 and 0 respectively.
This issue could occur on an older (non-C99) UNIX-like system, although it has not been reported.
Corrective actions:
Update CMake/herc22_Userland.cmake to test for stdbool.h
Update CMake/cmakeconfig.h.in to report the result of the above test.
Update msvc.makefiles.includes\HERC_FLAGS.msvrc to report the presence of stdbool.h when the build tool is VS2015 or better. A compile test is not required.
Update the SoftFloat-3a headers in Hyperion to match those in SoftFloat-3a.
Update configure.ac to test for stdbool.h (Ugh!)
Optional, but desirable: change the definition of bool in softfloat_stdTypes.h from int to char.
The above enable build from source. It "kicks the can down the road" a bit, though, when considering a stand-alone binary package for SoftFloat-3a; would would have to build one for C99 systems and one for pre-C99 systems.
srorso
commented
6 years ago
Issue affects both the current NMake build and the forthcoming CMake build.
Additional symptom: Incorrect binary floating point (BFP) results for selected instructions when compiled on Windows using the NMake build.
The version of SoftFloat-3a headers included with Hyperion unconditionally includes
stdbool.h. These headers are one commit back from the headers included in SoftFloat-3a, which make the #include conditional onHAVE_STDBOOL.H. The CMake build for SoftFloat-3a tests forstdbool.hand setsHAVE_STDBOOL.Haccordingly. Neither the CMake build for Hercules, the GNU Autotools build, nor the NMake Windows build test forstdbool.h.The incorrect BFP results occur because the NMake build does not report the presence of
stdbool.hon VS2015+ systems, and Hyperion is compiled with a different definition for the typebool(int, defined insoftfloat_stdTypes.hor worse, not at all) than SoftFloat (_bool, achar-sized type defined instdbool.h).There is no requirement that a c compiler map the type
boolto achar.The types and macros defined in
stdbool.hor substituted insoftfloat_stdTypes.hare used only withinieee.cor in the interface betweenieee.cand Softfloat-3a. Other Hercules headers defineTRUEandFALSEas 1 and 0 respectively.This issue could occur on an older (non-C99) UNIX-like system, although it has not been reported.
Corrective actions:
CMake/herc22_Userland.cmaketo test forstdbool.hCMake/cmakeconfig.h.into report the result of the above test.msvc.makefiles.includes\HERC_FLAGS.msvrcto report the presence ofstdbool.hwhen the build tool is VS2015 or better. A compile test is not required.configure.acto test forstdbool.h(Ugh!)boolinsoftfloat_stdTypes.hfrominttochar.The above enable build from source. It "kicks the can down the road" a bit, though, when considering a stand-alone binary package for SoftFloat-3a; would would have to build one for C99 systems and one for pre-C99 systems.