https://bugs.winehq.org/show_bug.cgi?id=48324
Bug ID: 48324 Summary: cl.exe fails to compile c++ due to error C2177: constant too big on float constant Product: Wine Version: 5.0-rc2 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvcrt Assignee: wine-bugs@winehq.org Reporter: rpisl@seznam.cz Distribution: ---
Commit c22af971c287933a137c9fbecc81823812e12b7a is a regression for me. I use 32bit cl.exe on 64bit Wine prefix. I was not affected by https://bugs.winehq.org/show_bug.cgi?id=48160. I have MSVC 2015 build tools installed using vs installer 2019. But since this commit, I get "error C2177: constant too big" on following simple program:
#include <stdio.h> void main() { printf("%f\n", 3.4028234663852886E38f); }
On Windows, it shows: 340282346638528859811704183484516925440.000000
3.4028234663852887E38f is also OK and shows the same, 3.4028234663852888E38f fails: error C2177: constant too big
On Wine 5.0-r2 3.4028234663852886E38f fails, 3.4028234663852885E38f is OK. On Wine 5.0-r1 it behaves like on Windows.
During the compilation, atof() is called: 0073:Call ucrtbase.atof(0143e180 "3.4028234663852886E38f") ret=01a20d25
https://bugs.winehq.org/show_bug.cgi?id=48324
Roman Pišl rpisl@seznam.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian CC| |rpisl@seznam.cz Keywords| |regression Regression SHA1| |c22af971c287933a137c9fbecc8 | |1823812e12b7a
https://bugs.winehq.org/show_bug.cgi?id=48324
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover@gmail.com
--- Comment #1 from Erich E. Hoover erich.e.hoover@gmail.com --- Wow. 1) I'm surprised that it's using atof (which is for doubles) 2) I'm surprised that this value works on Windows, since it's greater than FLT_MAX (3.402823466e+38F)
My guess would be that the value is being treated as a double, my new calculation is somewhat different from whatever MS does, and then when it gets typecast to a float it ends up slightly larger than what is allowed for FLT_MAX. Is this number from someplace special? Is there are a reason your application does not use FLT_MAX?
https://bugs.winehq.org/show_bug.cgi?id=48324
--- Comment #2 from Erich E. Hoover erich.e.hoover@gmail.com --- Are you sure this is where it has a problem? I just tried: float f = strtod("3.4028234663852886e38", NULL); ok(f == FLT_MAX, "f = %e\n", f); in a test and that worked...
https://bugs.winehq.org/show_bug.cgi?id=48324
--- Comment #3 from Erich E. Hoover erich.e.hoover@gmail.com --- Created attachment 66057 --> https://bugs.winehq.org/attachment.cgi?id=66057 tweak that might work
You know what? They're probably treating everything as a double and then manually comparing against FLT_MAX (if the number is supposed to be a float) while the number is still a double. Please try the attached patch and see if it fixes your problem. This will break a test on Linux i386, but if it works then it would justify trying to figure out another way to make that test pass.
https://bugs.winehq.org/show_bug.cgi?id=48324
--- Comment #4 from Roman Pišl rpisl@seznam.cz --- I can confirm that with this tweak it is possible to compile even with 3.4028234663852890E38f (it works only up to 3.4028234663852887E38f on Windows).
The msvcrt_test succeeds on wine64, but on wine32 it fails: string.c:1989: Test failed: d = 1000000000000000120942354671656868962382001670435578817768191183142249744630862900164152357803694488643546272066771136697843816472621283262276046411983423130707191163420128905684081263961470216866716118177799472091300320549064642593292288.000000
This is not really a major bug. I've found it when compiling a cross-platform code that compiles on Linux/Windows/msvc/gcc/clang/Keil so I think that it should work also with cl.exe on Wine.
https://bugs.winehq.org/show_bug.cgi?id=48324
--- Comment #5 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Roman Pišl from comment #4)
I can confirm that with this tweak it is possible to compile even with 3.4028234663852890E38f (it works only up to 3.4028234663852887E38f on Windows). ...
That's wonderful news. I will try to put together a fix that doesn't break the tests on wine32 and adds a test for 3.4028234663852887e38 (working with a slightly larger value should not be a problem).
https://bugs.winehq.org/show_bug.cgi?id=48324
Erich E. Hoover erich.e.hoover@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #66057|0 |1 is obsolete| |
--- Comment #6 from Erich E. Hoover erich.e.hoover@gmail.com --- Created attachment 66064 --> https://bugs.winehq.org/attachment.cgi?id=66064 fix strtod FLT_MAX behavior
Please try the attached patch and see if it works, hopefully it will do the trick (without breaking the tests).
https://bugs.winehq.org/show_bug.cgi?id=48324
--- Comment #7 from Roman Pišl rpisl@seznam.cz --- Created attachment 66074 --> https://bugs.winehq.org/attachment.cgi?id=66074 msvcrt/string - added tests
I can confirm that the patch works and tests succeed in both wine32 and wine64.
However.. ;-) .. there is an analogical problem with FLT_MIN. See attached tests that succeed on Windows and also on Linux/gcc but fail on Wine (the two that compare FLT_MIN).
Again, 1.1754943508222875e-38 is a common representation of minimal float and that should probably also directly compare to FLT_MIN in the double representation. But maybe I'm digging too deeply..
https://bugs.winehq.org/show_bug.cgi?id=48324
--- Comment #8 from Erich E. Hoover erich.e.hoover@gmail.com --- (In reply to Roman Pišl from comment #7)
... I can confirm that the patch works and tests succeed in both wine32 and wine64.
Great! Hopefully AJ is okay with it.
However.. ;-) .. there is an analogical problem with FLT_MIN. See attached tests that succeed on Windows and also on Linux/gcc but fail on Wine (the two that compare FLT_MIN). ...
Without knowing the exact algorithm that MS is using there's no way for me to replicate every edge case. If someone comes along with a program that relies on this behavior then we'll have to do better, but I'm willing to accept this difference for now.
https://bugs.winehq.org/show_bug.cgi?id=48324
--- Comment #9 from Roman Pišl rpisl@seznam.cz --- I understand and it sounds reasonable, but.. according to the standard: if a double-precision number is converted to a decimal string with at least 17 significant digits, and then converted back to double-precision representation, the final result must match the original number. This is violated in current implementation.
https://bugs.winehq.org/show_bug.cgi?id=48324
--- Comment #10 from Erich E. Hoover erich.e.hoover@gmail.com --- Would you check and see if commit 27b9a420ea87fd85c0c933b7db77a9efb22f94cf fixes this bug (FLT_MAX issue) for you?
(In reply to Roman Pišl from comment #9)
I understand and it sounds reasonable, but.. according to the standard: if a double-precision number is converted to a decimal string with at least 17 significant digits, and then converted back to double-precision representation, the final result must match the original number. This is violated in current implementation.
Really, if the GCC code were LGPL 2.1 then I'd just go grab that since it's well tested, but unfortunately GCC is GPL 3. Would you mind opening a separate bug for this and adding me to the CC list? We can probably get some "todo_wine" tests added now, but fixing it for real will probably need to wait until after code freeze is over (unless the solution is really compelling).
https://bugs.winehq.org/show_bug.cgi?id=48324
Roman Pišl rpisl@seznam.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #11 from Roman Pišl rpisl@seznam.cz --- I can confirm that 27b9a420ea87fd85c0c933b7db77a9efb22f94cf fixes the issue. I will test it thoroughly after 5.0-rc3 is released and also look closer at the tests.
https://bugs.winehq.org/show_bug.cgi?id=48324
Gijs Vermeulen gijsvrm@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |27b9a420ea87fd85c0c933b7db7 | |7a9efb22f94cf
https://bugs.winehq.org/show_bug.cgi?id=48324
Roman Pišl rpisl@seznam.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|cl.exe fails to compile c++ |cl.exe fails to compile |due to error C2177: |valid code with float |constant too big on float |constant due to error |constant |C2177: constant too big
https://bugs.winehq.org/show_bug.cgi?id=48324
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #12 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.0-rc3.