Follow-Up: R on FC4 - R-devel

Mon, Aug 1, 2005 10:04 AM #

Dear List,

A few weeks ago a discussion took place regarding Fedora Core 4 and
compiling R on that platform using the new version 4 of gcc and its
gfortran compiler.

gcc was recently updated to 4.0.1 on FC4 (4.0.1-5 in Red Hat Land) so I
thought I'd give compiling R a go on my laptop which needed updating
anyway. I've had trouble using the optimisation flags I used to use
under FC3 with FC4 and the compatibility version of g77, so I wanted to
see if I could compile with the flags I was used to (under FC3) with
gfortran on FC4. I was compiling with no extra flags on g77 to get it to
compile at all on my FC4 desktop.

R-patched compiles and make check-all succeeds on FC with gcc/g+
+/gfortran using these options at least: -g -O3 -m32 -pipe -mcpu=i386 -
mtune=pentium3m

R-devel compiles without error (same set of flags as above) but fails
make check-all in p-r-random-tests.R - the relevant section of p-r-
random-tests.Rout.fail is:

...

norm() PASSED
[1] TRUE

norm(mean = 5, sd = 3) PASSED
[1] TRUE

gamma(shape = 0.1) PASSED
[1] TRUE

gamma(shape = 0.2) PASSED
[1] TRUE

gamma(shape = 10) FAILED
Error in dkwtest("gamma", shape = 10) : dkwtest failed
Execution halted

Is this a tolerance setting in R's tests not being met or is this
indicative of a bad compilation of R-Devel on FC4 with gfortran?

Both these compilations was using the svn-acquired sources from this
afternoon:
R-patched = revision 35098
R-Devel = revision 35098

HTH

G

%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Gavin Simpson                     [T] +44 (0)20 7679 5522
ENSIS Research Fellow             [F] +44 (0)20 7679 7565
ENSIS Ltd. & ECRC                 [E] gavin.simpsonATNOSPAMucl.ac.uk
UCL Department of Geography       [W] http://www.ucl.ac.uk/~ucfagls/cv/
26 Bedford Way                    [W] http://www.ucl.ac.uk/~ucfagls/
London.  WC1H 0AP.
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%

Thomas Lumley

Mon, Aug 1, 2005 10:16 AM #

On Mon, 1 Aug 2005, Gavin Simpson wrote:

Try this again -- it is a random test.  If it fails again then something 
is wrong.  The tolerance on these tests is not very tight, certainly 
nowhere near rounding error.

 	-thomas

Gavin Simpson

Mon, Aug 1, 2005 11:09 AM #

On Mon, 2005-08-01 at 10:16 -0700, Thomas Lumley wrote:

Thanks Thomas,

A re-compile with the same options of R-Devel went through without
error.

So far so good with FC4, gcc4, gfortran and R!

All the best,

G

%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
Gavin Simpson                     [T] +44 (0)20 7679 5522
ENSIS Research Fellow             [F] +44 (0)20 7679 7565
ENSIS Ltd. & ECRC                 [E] gavin.simpsonATNOSPAMucl.ac.uk
UCL Department of Geography       [W] http://www.ucl.ac.uk/~ucfagls/cv/
26 Bedford Way                    [W] http://www.ucl.ac.uk/~ucfagls/
London.  WC1H 0AP.
%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%

Peter Dalgaard

Mon, Aug 1, 2005 11:43 AM #

Gavin Simpson <gavin.simpson at ucl.ac.uk> writes:

The problem affecting the Fedora Extras RPM is still there with the
new compilers though:

 -Wp,-D_FORTIFY_SOURCE=2 

combined with -O or -O2 causes a strange printing bug:

[,1]
[1,]

(You don't have to use that option of course, but it suggests that not
all is well with the optimizer. And the Fedora maintainer seem set on
using it, which is a bit of a problem.)

O__  ---- Peter Dalgaard             ?ster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907

Peter Dalgaard

Tue, Aug 2, 2005 5:55 PM #

Peter Dalgaard <p.dalgaard at biostat.ku.dk> writes:

....

I'm fairly sure by now that this is actually a bug in R, not gcc. We
have the same internal buffer structure used in EncodeReal and in
Rsprintf, and the return value of the former is buffer->data
which is reallocated by the latter.

That means that constructions of the form

pbuf = Rsprintf("%s", EncodeReal(REAL(tmp)[0], w, d, e, OutDec));

are playing with fire. There are quite a few other similar
constructions involving Encode*.

I suspect is is necessary to copy the result of
EncodeReal(REAL(tmp)[0], w, d, e, OutDec) to temp storage, or -
probably easier - use a separate buffer for Rsprintf.

O__  ---- Peter Dalgaard             ?ster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907