lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] MinGW-w64 gcc-6.3.0 std::rint() anomaly


From: Vadim Zeitlin
Subject: Re: [lmi] MinGW-w64 gcc-6.3.0 std::rint() anomaly
Date: Sun, 20 Aug 2017 21:31:20 +0200

On Sat, 19 Aug 2017 16:36:30 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--Do you have any idea why 'fenv_lmi_test' fails with MinGW-w64
GC> gcc-6.3.0, whereas it succeeded with earlier versions?

 Unfortunately my only idea is that it's a compiler bug and a pretty bad
one at that. I can reproduce the problem with the following very simple
program:

---------------------------------- >8 --------------------------------------
#include <cfenv>
#include <cmath>
#include <stdio.h>

int main()
{
    printf("--- Test built with gcc %d.%d.%d ---\n",
           __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__ );

    auto const x = -2.5;

    printf("Default round mode : rint(%g)=%g\n", x, std::rint(x));
    fesetround(FE_DOWNWARD);
    printf("Downward round mode: rint(%g)=%g\n", x, std::rint(x));

    return 0;
}
---------------------------------- >8 --------------------------------------

and, looking at the difference in the generated assembly with -O0 and -O1
(it's the same as with -O2), I see that the compiler has simply optimized
away the second call to rint() and reuses the result returned by the first
one.

 It looks like there ought to be some way to prevent it from doing this
using "volatile", but I didn't manage to do it quickly and I am not sure
it's really worth doing this because it doesn't seem clear how could we use
any such workaround in production anyhow.

 Worse, I don't really know how can a compiler capable of eliminating
function calls like this be trusted at all. And, just to be fair to MinGW
people for once, this is not their problem at all as I can also reproduce
the same bug with the native g++ 6.4 under Linux. And it's still present in
g++ 7.1 too (but not 5.4.1, FWIW). I've created a bug report for it at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81906 but, again, this doesn't
really help us right now.

 Sorry for the bad news,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]