Jeroen Ooms
2015-Sep-14 12:49 UTC
[Rd] Optimization bug when byte compiling with gcc 5.2.0 on windows
When building R-devel with gcc 5.2.0 (mingw-w64 v4) on Windows, make check fails reg-tests-1b.R at the following check: x <- c(1:2, NA) sx <- sd(x) !is.nan(sx) Here 'sx' should be 'NA' but it is 'NaN'. It turns out this problem only appears when the function is byte compiled with optimization level 3: mysd <- function (x, na.rm = FALSE) sqrt(var(if (is.vector(x)) x else as.double(x), na.rm = na.rm)) mysd(x) # [1] NA compiler::cmpfun(mysd, list(optimize = 1L))(x) # [1] NA compiler::cmpfun(mysd, list(optimize = 2L))(x) # [1] NA compiler::cmpfun(mysd, list(optimize = 3L))(x) # [1] NaN The problem does not appear with gcc 5.2.0 on Debian, and also not with gcc 4.9.3 on Windows. Where do I start debugging this? The disassembled output from the compiled functions is here: https://gist.github.com/jeroenooms/3206945a6db6680a9c5c
Simon Urbanek
2015-Sep-14 13:27 UTC
[Rd] Optimization bug when byte compiling with gcc 5.2.0 on windows
Jeroen, the difference is that level 3 is using the internal implementation of sqrt in the compiler instead of calling the sqrt function. The internal path goes to R_sqrt which is defined as # define R_sqrt(x) (ISNAN(x) ? x : sqrt(x)) so you could check if that is where the problem happens. It theory NA should yield itself, but perhaps the compiler thinks all NANs are equal and will return a constant one. If that's not it, then something else in the direct FastMath1(R_sqrt, R_SqrtSym) path... Cheers, Simon> On Sep 14, 2015, at 8:49 AM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote: > > When building R-devel with gcc 5.2.0 (mingw-w64 v4) on Windows, make > check fails reg-tests-1b.R at the following check: > > x <- c(1:2, NA) > sx <- sd(x) > !is.nan(sx) > > Here 'sx' should be 'NA' but it is 'NaN'. It turns out this problem > only appears when the function is byte compiled with optimization > level 3: > > mysd <- function (x, na.rm = FALSE) > sqrt(var(if (is.vector(x)) x else as.double(x), na.rm = na.rm)) > > mysd(x) > # [1] NA > compiler::cmpfun(mysd, list(optimize = 1L))(x) > # [1] NA > compiler::cmpfun(mysd, list(optimize = 2L))(x) > # [1] NA > compiler::cmpfun(mysd, list(optimize = 3L))(x) > # [1] NaN > > The problem does not appear with gcc 5.2.0 on Debian, and also not > with gcc 4.9.3 on Windows. Where do I start debugging this? The > disassembled output from the compiled functions is here: > https://gist.github.com/jeroenooms/3206945a6db6680a9c5c > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
luke-tierney at uiowa.edu
2015-Sep-14 13:36 UTC
[Rd] Optimization bug when byte compiling with gcc 5.2.0 on windows
I believe the issue is that on Windows the sqrt function when called with a NaN does not return the same NaN, as it does on other platforms. We have #if (defined(_WIN32) || defined(_WIN64)) && defined(__GNUC__) && \ __GNUC__ <= 4 # define R_sqrt(x) (ISNAN(x) ? x : sqrt(x)) #else # define R_sqrt sqrt #endif for implementing the SQRT opcode. I suspect this came from Duncan Murdoch; I don't know the reason for restricting to __GNUC__ <= 4. I seem to recall that there are other places in the code where we have similar workarounds but I can't find them at the moment. The builtin sqrt always pretests with ISNAN. Best, luke On Mon, 14 Sep 2015, Jeroen Ooms wrote:> When building R-devel with gcc 5.2.0 (mingw-w64 v4) on Windows, make > check fails reg-tests-1b.R at the following check: > > x <- c(1:2, NA) > sx <- sd(x) > !is.nan(sx) > > Here 'sx' should be 'NA' but it is 'NaN'. It turns out this problem > only appears when the function is byte compiled with optimization > level 3: > > mysd <- function (x, na.rm = FALSE) > sqrt(var(if (is.vector(x)) x else as.double(x), na.rm = na.rm)) > > mysd(x) > # [1] NA > compiler::cmpfun(mysd, list(optimize = 1L))(x) > # [1] NA > compiler::cmpfun(mysd, list(optimize = 2L))(x) > # [1] NA > compiler::cmpfun(mysd, list(optimize = 3L))(x) > # [1] NaN > > The problem does not appear with gcc 5.2.0 on Debian, and also not > with gcc 4.9.3 on Windows. Where do I start debugging this? The > disassembled output from the compiled functions is here: > https://gist.github.com/jeroenooms/3206945a6db6680a9c5c > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >-- Luke Tierney Ralph E. Wareham Professor of Mathematical Sciences University of Iowa Phone: 319-335-3386 Department of Statistics and Fax: 319-335-3017 Actuarial Science 241 Schaeffer Hall email: luke-tierney at uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
Duncan Murdoch
2015-Sep-14 14:16 UTC
[Rd] Optimization bug when byte compiling with gcc 5.2.0 on windows
On 14/09/2015 9:36 AM, luke-tierney at uiowa.edu wrote:> I believe the issue is that on Windows the sqrt function when called > with a NaN does not return the same NaN, as it does on other platforms. > We have > > #if (defined(_WIN32) || defined(_WIN64)) && defined(__GNUC__) && \ > __GNUC__ <= 4 > # define R_sqrt(x) (ISNAN(x) ? x : sqrt(x)) > #else > # define R_sqrt sqrt > #endif > > for implementing the SQRT opcode. I suspect this came from Duncan > Murdoch; I don't know the reason for restricting to __GNUC__ <= 4.That was an update to keep the workaround for gcc 4.9.2. The previous code restricted the change to 4.6.x or earlier. I think the reason for the earlier restriction is the assumption that eventually gcc will be fixed and this workaround won't be necessary, but apparently 5.2.0 still has the same problem. Duncan Murdoch> I > seem to recall that there are other places in the code where we have > similar workarounds but I can't find them at the moment. > > The builtin sqrt always pretests with ISNAN. > > Best, > > luke > > > > On Mon, 14 Sep 2015, Jeroen Ooms wrote: > > > When building R-devel with gcc 5.2.0 (mingw-w64 v4) on Windows, make > > check fails reg-tests-1b.R at the following check: > > > > x <- c(1:2, NA) > > sx <- sd(x) > > !is.nan(sx) > > > > Here 'sx' should be 'NA' but it is 'NaN'. It turns out this problem > > only appears when the function is byte compiled with optimization > > level 3: > > > > mysd <- function (x, na.rm = FALSE) > > sqrt(var(if (is.vector(x)) x else as.double(x), na.rm = na.rm)) > > > > mysd(x) > > # [1] NA > > compiler::cmpfun(mysd, list(optimize = 1L))(x) > > # [1] NA > > compiler::cmpfun(mysd, list(optimize = 2L))(x) > > # [1] NA > > compiler::cmpfun(mysd, list(optimize = 3L))(x) > > # [1] NaN > > > > The problem does not appear with gcc 5.2.0 on Debian, and also not > > with gcc 4.9.3 on Windows. Where do I start debugging this? The > > disassembled output from the compiled functions is here: > > https://gist.github.com/jeroenooms/3206945a6db6680a9c5c > > > > ______________________________________________ > > R-devel at r-project.org mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > >
Maybe Matching Threads
- Optimization bug when byte compiling with gcc 5.2.0 on windows
- Optimization bug when byte compiling with gcc 5.2.0 on windows
- Optimization bug when byte compiling with gcc 5.2.0 on windows
- Optimization bug when byte compiling with gcc 5.3.0 on windows
- how to use apply with two variables