RH 9 and R 1.7.0 Beta - Errors Resolved

Hi all,

As you may recall, earlier this week I posted about errors in make check
using 1.7.0 Beta under RH 9.

Peter kindly contacted me off list and we have been running some checks
and possible resolutions the past couple of days.

The errors turned out to be (run individually):

 > !is.nan(c(1.,NA))

[1]  TRUE FALSE

 > is.nan(c   (1.,NaN,NA))

[1] FALSE  TRUE  TRUE

 > is.nan(list(1.,NaN,NA))

[1] FALSE  TRUE FALSE

 > is.nan(as.numeric(NA))

[1] TRUE

After doing some debugging, we identified some problems that ultimately
led us to the conclusion that there are optimization problems with the
current gcc in RH 9, which is:

gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

We confirmed this running

./configure CFLAGS="-O0 -g"

and I was able to run make check without errors.

Bottom line, it appears that R_NaReal was not being set properly. It
would take the value of nan(0x8000000000000) instead of
nan(0x80000000007a2). This is set in R_NaReal = R_ValueOfNA().

The present version in arithmetic.c is:

  117 static double R_ValueOfNA(void)
  118 {
  119     ieee_double x;
  120     x.word[hw] = 0x7ff00000;
  121     x.word[lw] = 1954;
  122     return x.value;
  123 }

The change is in line 119 to:

volatile ieee_double x;

This has resolved the problem and now results in no errors being
reported during make check with the default ./configure.

Thus, now using:

R : Copyright 2003, The R Development Core Team
Version 1.7.0 Under development (unstable) (2003-04-05)

I get:

 > !is.nan(c(1.,NA))

[1] TRUE TRUE

 > is.nan(c   (1.,NaN,NA))

[1] FALSE  TRUE FALSE

 > is.nan(list(1.,NaN,NA))

[1] FALSE  TRUE FALSE

 > is.nan(as.numeric(NA))

[1] FALSE

Many thanks to Peter for his patience and support is guiding me through
this process!  Peter has indicated that he will incorporate this change
into the base code.

Best regards,

Marc Schwartz

I don't seem to have this problem on Mandrake 9.1 which has 
gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) and using R-1.7.0beta2003-03-31
compiled with the defaults. That is, I get the latter results even without the
fix.

Paul Gilbert

Paul Gilbert wrote:

I don't seem to have this problem on Mandrake 9.1 which has 
gcc 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk) and using R-1.7.0beta2003-03-31
compiled with the defaults. That is, I get the latter results even without the
fix.

Paul Gilbert

The only thought that I can offer is that RH has done something to the 
version of gcc released with RH 9.

Martyn and I had an offlist exchange last week and he is going to be 
installing RH 9 on his home system, if he has not done so already. It 
will be interesting to see if he can confirm or deny the behavior that I 
have seen with the "pre-fix" code.

If he can, then it would suggest that there is something with the RH 9 
version of gcc. If not, then perhaps there is something with my 
particular install, though I did do a "clean" install and not an upgrade 
from RH 8.0 and I have installed all RH 9 updates via RHN.

Note the specfic details of 'gcc --version' for RH 9:

gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

The "official" release of 3.2.2 from gcc.gnu.org is dated February 05, 
2003. So there is at least some potential for distribution specific 
issues it would seem.