[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #5 from Bruno Haible --- (In reply to jos...@codesourcery.com from comment #4) > You need to use -fexcess-precision=standard (or -msse2 -mfpmath=sse) for > predictable results from double arithmetic on 32-bit x86. If you do that, > do you still see such a problem? If I pass -fexcess-precision=standard or -mfpmath=sse (no need for -msse2 in this case), the test passes. However, something has evidently changed (regressed) in the inliner: 'volatile double', put in sufficiently many places, has the same effect as -fexcess-precision=standard (before gcc 7 and in gcc 7). What has changed, is that if I have 'volatile double' only in the signature of the 'equalfn' function that gets inlined, since gcc 7 this information that the values should be passed as IEEE doubles (discarding excess precision) gets lost.
[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #4 from joseph at codesourcery dot com --- You need to use -fexcess-precision=standard (or -msse2 -mfpmath=sse) for predictable results from double arithmetic on 32-bit x86. If you do that, do you still see such a problem? If not, this is just a duplicate of bug 323 (and what's a volatile access is irrelevant).
[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- In response to DR476 the C standard has been clarified (or is in the process of being clarified, as the DR is still open) that a "volatile access" is intended to mean an access to an object via a volatile-qualified lvalue. I believe C++ has discussed adopting a similar clarification in response to the C DR, if it hasn't done so yet. http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_476
[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #2 from Marc Glisse --- IIRC, the standard provides guarantees for volatile objects. Here, you are accessing a non-volatile object through a volatile type, and if the compiler can find out about the underlying object, it can ignore 'volatile'. At least I seem to remember discussions along those lines in the past.
[Bug c/84190] [7 Regression] double arithmetic on x86 no longer rounds to nearest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84190 --- Comment #1 from Bruno Haible --- It works when I declare ys1, ys2, zs1, zs2 as 'volatile double' instead of 'double'. But I should not be needing to do this, because the only uses of these 4 variables is as arguments to equalfn, which takes 'volatile double *' arguments, which ought to already do the truncation from extended-double format to double format.
