I had promised to report on tests of gcc-4.0.1, and have now tracked down all the outstanding issues. I am comparing gcc3 (gcc-3.4.4 including g77) and gcc4 (gcc-4.0.1 including gfortran) on FC3, both i686 and x86_64 (the latter both 64-bit and 32-bit builds). All compiled from the sources (the FC3 update to 3.4.4 was not out when I started this). The bottom line is that 4.0.1 shows none of the serious errors that 4.0.0 showed, but was always slower (usually 4-10% slower) than gcc3 and (see below) about 25 CRAN packages fail only about half of which are attributable to deficiences in the packages. The differences between the outputs has shown some places where R is more sensitive to rounding errors than might have been thought. Amongst these are - ppr (that was known) - lowess, which can be extremely sensitive to the number of iterations allowed, as shown by panel 8 in example(attenu). - contouring, in particular the exact place contour labels are placed. - str, which depended on a test ob == signif(ob, digits.d), and signif() was unnecessarily causing rounding error by dividing by a negative power of 10 (now fixed). - the extreme test in example(smooth.spline), which showed quite large differences. Amongst CRAN packages: RSvgDevice is said to have invalid C acepack, deldir, fMultivar, fOptions, fSeries, frailtypack, gap, gcmrec, hmm.discnp, labdsv, survrec have invalid Fortran. (Most of these have been reported to the maintainers some time ago.) Geneland infinite loops NISTnls, gss, relsurv fail their tests SparseM, asypow, mvtnorm, party, subselect segfault ade4 has an LAPACK error (similar to those seen before) -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
Prof Brian Ripley wrote:>I had promised to report on tests of gcc-4.0.1, and have now tracked down >all the outstanding issues. > >I am comparing gcc3 (gcc-3.4.4 including g77) and gcc4 (gcc-4.0.1 >including gfortran) on FC3, both i686 and x86_64 (the latter both 64-bit >and 32-bit builds). All compiled from the sources (the FC3 update to >3.4.4 was not out when I started this). > >The bottom line is that 4.0.1 shows none of the serious errors that 4.0.0 >showed, but was always slower (usually 4-10% slower) than gcc3 and (see >below) about 25 CRAN packages fail only about half of which are >attributable to deficiences in the packages. > >The differences between the outputs has shown some places where R is more >sensitive to rounding errors than might have been thought. Amongst these >are > >- ppr (that was known) >- lowess, which can be extremely sensitive to the number of iterations > allowed, as shown by panel 8 in example(attenu). >- contouring, in particular the exact place contour labels are placed. >- str, which depended on a test ob == signif(ob, digits.d), and signif() > was unnecessarily causing rounding error by dividing by a negative power > of 10 (now fixed). >- the extreme test in example(smooth.spline), which showed quite large > differences. > >Amongst CRAN packages: > >RSvgDevice is said to have invalid C > >acepack, deldir, fMultivar, fOptions, fSeries, frailtypack, gap, gcmrec, >hmm.discnp, labdsv, survrec > >have invalid Fortran. (Most of these have been reported to the maintainers >some time ago.) > >Geneland infinite loops >NISTnls, gss, relsurv fail their tests >SparseM, asypow, >The fortran left in asypow does things (noncentral chisquare distribution) which are available at the R level. If problem if with the fortran I remove it completely. Kjetil> mvtnorm, party, subselect segfault >ade4 has an LAPACK error (similar to those seen before) > > >-- Kjetil Halvorsen. Peace is the most effective weapon of mass construction. -- Mahdi Elmandjra -- Internal Virus Database is out-of-date. Checked by AVG Anti-Virus.