2015-10-16 15:24 GMT+02:00 JonY <[email protected]>: > On 10/13/2015 07:14, Richard Copley wrote: >> __mingw_vprintf for the "%a" (hexfloat) type gives incorrect output, >> in g++. This is with the mingw-builds toolchain (64-bit targets, >> Windows threads, SEH exceptions, version 5.2.0, revision 0). The >> toolchain targeting 32-bit executables is also affected. >> >> See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67932 (invalid >> bug report created against gcc libstdc++ by me for the same issue, >> with more test cases). >> >> I compiled these two programs with "g++ -Wall -std=c++11 -o x.exe x.cpp": >> >> // Source file "test1\x.cpp" (program output "0x0p-63") >> #include <cstdio> >> int main () { printf ("%a", 0x1.000008p+0); } >> >> // Source file "test2\x.cpp" (program output "0x1.000008p+0") >> #include <stdio.h> >> int main () { printf ("%a", 0x1.000008p+0); } >> >> Source file "test1\x.cpp" compiles with no warnings but gives >> incorrect output, "0x0p-63". >> Source file "test2\x.cpp" gives the correct output "0x1.000008p+0" but >> produces warnings ("unknown conversion type character 'a' in format", >> "too many arguments for format"). >> >> Comparing the preprocessed sources, "test1\x.cpp" uses __mingw_vprintf >> and "test2\x.cpp" does not. (I think test2\x.cpp uses printf from >> msvcrt.dll, which is version 7.0.10240.16384 (10 July 2015) on my >> Windows 10 system.) >> > > This is a kniwn issue, but unfortunately, I can't read or figure out > hex-float in respect to IEEE754 to understand what is going on. > > Kai care to look into it?
Hmm, this seems to be burried deep in gdtoa. Unfortunately I don't have right now time to look into it. Nevertheless we might want to consider a replace of the printf-formatter in general, and especially the gdtoa bits, Kai ------------------------------------------------------------------------------ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
