[Bug 48324] New: cl.exe fails to compile c++ due to error C2177: constant too big on float constant
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(a)winehq.org Reporter: rpisl(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 Roman Pišl <rpisl(a)seznam.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- Distribution|--- |Debian CC| |rpisl(a)seznam.cz Keywords| |regression Regression SHA1| |c22af971c287933a137c9fbecc8 | |1823812e12b7a -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 Erich E. Hoover <erich.e.hoover(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover(a)gmail.com --- Comment #1 from Erich E. Hoover <erich.e.hoover(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 --- Comment #2 from Erich E. Hoover <erich.e.hoover(a)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... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 --- Comment #3 from Erich E. Hoover <erich.e.hoover(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 --- Comment #4 from Roman Pišl <rpisl(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 --- Comment #5 from Erich E. Hoover <erich.e.hoover(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 Erich E. Hoover <erich.e.hoover(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #66057|0 |1 is obsolete| | --- Comment #6 from Erich E. Hoover <erich.e.hoover(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 --- Comment #7 from Roman Pišl <rpisl(a)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.. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 --- Comment #8 from Erich E. Hoover <erich.e.hoover(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 --- Comment #9 from Roman Pišl <rpisl(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 --- Comment #10 from Erich E. Hoover <erich.e.hoover(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 Roman Pišl <rpisl(a)seznam.cz> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Roman Pišl <rpisl(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |27b9a420ea87fd85c0c933b7db7 | |7a9efb22f94cf -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 Roman Pišl <rpisl(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=48324 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #12 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 5.0-rc3. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla