#733 "%a" and "%La" formatting seriously broken

[Sisyphus]

Hi,
I find that "%a" and "%La" formattingfails to provide correct output unless there are at least 31 bits between the most siginificant set bit and the least siginificant set bit of the mantissa.
Otherwise, the output is zero.
For example, printf( "%a", 0x8.1234561p+2) will output 0x0p-58 because there's only 30 bits between the most siginificant and least significant set bits.
But printf( "%a", 0x8.12345618p+2) will correctly output 0x8.12345618p+2.

These values that get wrongly reported as zero are assigned correctly - as shown by the correct values reported for them by "%.16e" formatting.
And, AFAICT, the exponent values are largely irrelevant - though they influence the exponent of the bogus zero, and will allow the detection of an infinity.
For example, printf("%a", 0x1.0p+1024) will correctly report 'inf', though printf(
%a", 0x1.0p+1023) will incorrectly report 0x0p+960.

See the attached simple demo.
It allows user input of a value, then displays that value formatted according to both "%a" and "%.16e" specifiers.

That demo doesn't provide testing of "%La" formatting of long double values because strtold() doesn't work with hex inputs (see bug 725) - and I didn't want to go to the trouble of constructing suitable values from decimal inputs.
But it's the same situation - long double mantissas also need to be more than 32 bits long (as measured from most significant set bit to least significant set bit), or "%La" will report a zero value.

I'm curently using gcc version 7.2.0 (i686-posix-dwarf-rev1, Built by MinGW-W64 project) and gcc version 7.2.0 (x86_64-posix-seh-rev1, Built by MinGW-W64 project).
And I've also tested with mingw-w64 compilers going back to 4.7.3.
The same buggy behaviour exists throughout all of those distros - but not with gcc on Ubuntu, and not with my mingw.org port of gcc-4.7.0.

Cheers,
Rob

[LIU Hao]

This looks like a duplicate of #459 . On current master this issue is not reproducible.

[LIU Hao]

Please look for a file named _mingw_mac.h in your mingw-w64 include directory and copy the values of __MINGW64_VERSION_MAJOR, __MINGW64_VERSION_MINOR and __MINGW64_VERSION_BUGFIX here.

[Sisyphus]

Respectively they are 5, 0, and non-existent.
(I believe I have runtime version 5.0.2 - which, UIM, was the last runtime to not specify a "BUGFIX" value .)

I agree that this is a duplicate of bug 459.
Good to hear that it has been fixed in Master.

[LIU Hao]

This has been fixed on 9cb3a1a9c6ccefd6c1b06c24402ca8cf3dd7b3b8, which is not in the branch v5.x.

[LIU Hao]

I cherry-picked it to v5.x and this can be closed now.