make check of R-alpha_2006-04-08_r37675 fails: qbeta

make check of R-alpha_2006-04-08_r37675 fails on Debian GNU/Linux 3.1 running
on an Intel P4 computer.
version
_                                      
platform       i686-pc-linux-gnu                      
arch           i686                                   
os             linux-gnu                              
system         i686, linux-gnu                        
status         alpha                                  
major          2                                      
minor          3.0                                    
year           2006                                   
month          04                                     
day            08                                     
svn rev        37675                                  
language       R                                      
version.string Version 2.3.0 alpha (2006-04-08 r37675)

I'm using ATLAS with the SSE2 extensions, and get the same error with ATLAS
3.2.1 (packages atlas2-* 3.2.1ln-15 in Debian) and 3.6.0 (packages atlas3-*
3.6.0-19 in Debian).  I've also tried without external BLAS (--without-blas),
but the error still occurs.

43 (0) $ ./configure
[...]
R is now configured for i686-pc-linux-gnu

  Source directory:          .
  Installation directory:    /usr/local

  C compiler:                gcc  -g -O2 -std=gnu99
  Fortran 77 compiler:       g77  -g -O2

  C++ compiler:              g++  -g -O2
  Fortran 90/95 compiler:    g77 -g -O2

  Interfaces supported:      X11, tcltk
  External libraries:        readline, BLAS(ATLAS)
  Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS
  Options enabled:           R profiling

  Recommended packages:      yes

44 (0) $ make
[...]

45 (0) $ make check
[...]
running code in 'd-p-q-r-tests.R' ... OK
comparing 'd-p-q-r-tests.Rout' to './d-p-q-r-tests.Rout.save' ...777,778d776
< Warning message:
< full precision was not achieved in 'qbeta' 
make[3]: *** [d-p-q-r-tests.Rout] Error 1
[...]

46 (0) $ diff tests/d-p-q-r-tests.Rout.{save,fail}
3c3
< Version 2.3.0 alpha (2006-04-03 r37628)
---
Version 2.3.0 alpha (2006-04-08 r37675)
791a792,793
Warning message:
full precision was not achieved in 'qbeta' 
1073c1075
< Time elapsed:  2.53 0.03 2.55 0 0 
---
Time elapsed:  4.939 0.024 4.967 0 0 
The (hopefully) interesting part of tests/d-p-q-r-tests.Rout.fail:
## Check q*(p* ( log ), log) = identity
All.eq(Rbeta,   qbeta    (log(Pbeta), shape1 = .8, shape2 = 2, log=TRUE))
[1] TRUE
Warning message:
full precision was not achieved in 'qbeta' 

Please let me know if there is more I can provide to help trace this!
Bj?rn-Helge Mevik
bhs2 at mevik.net (Bj?rn-Helge Mevik) writes:
make check of R-alpha_2006-04-08_r37675 fails on Debian GNU/Linux 3.1 running
on an Intel P4 computer.

version
               _                                      
platform       i686-pc-linux-gnu                      
arch           i686                                   
os             linux-gnu                              
system         i686, linux-gnu                        
status         alpha                                  
major          2                                      
minor          3.0                                    
year           2006                                   
month          04                                     
day            08                                     
svn rev        37675                                  
language       R                                      
version.string Version 2.3.0 alpha (2006-04-08 r37675)

I'm using ATLAS with the SSE2 extensions, and get the same error with ATLAS
3.2.1 (packages atlas2-* 3.2.1ln-15 in Debian) and 3.6.0 (packages atlas3-*
3.6.0-19 in Debian).  I've also tried without external BLAS (--without-blas),
but the error still occurs.

43 (0) $ ./configure
[...]
R is now configured for i686-pc-linux-gnu

  Source directory:          .
  Installation directory:    /usr/local

  C compiler:                gcc  -g -O2 -std=gnu99
  Fortran 77 compiler:       g77  -g -O2

  C++ compiler:              g++  -g -O2
  Fortran 90/95 compiler:    g77 -g -O2

  Interfaces supported:      X11, tcltk
  External libraries:        readline, BLAS(ATLAS)
  Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS
  Options enabled:           R profiling

  Recommended packages:      yes

44 (0) $ make
[...]

45 (0) $ make check
[...]
running code in 'd-p-q-r-tests.R' ... OK
comparing 'd-p-q-r-tests.Rout' to './d-p-q-r-tests.Rout.save' ...777,778d776
< Warning message:
< full precision was not achieved in 'qbeta' 
make[3]: *** [d-p-q-r-tests.Rout] Error 1
[...]

46 (0) $ diff tests/d-p-q-r-tests.Rout.{save,fail}
3c3
< Version 2.3.0 alpha (2006-04-03 r37628)
---
Version 2.3.0 alpha (2006-04-08 r37675)
791a792,793
Warning message:
full precision was not achieved in 'qbeta' 
1073c1075
< Time elapsed:  2.53 0.03 2.55 0 0 
---
Time elapsed:  4.939 0.024 4.967 0 0 
The (hopefully) interesting part of tests/d-p-q-r-tests.Rout.fail:

## Check q*(p* ( log ), log) = identity
All.eq(Rbeta,   qbeta    (log(Pbeta), shape1 = .8, shape2 = 2, log=TRUE))
[1] TRUE
Warning message:
full precision was not achieved in 'qbeta' 

Please let me know if there is more I can provide to help trace this!
I suspect that this is related to recent changes in the zero-finder,
and that it is relatively benign. (If it is the effect that I'm
thinking of, then the warning is spurious, and it is mainly a matter
of whether we want to try to get rid of the warning or update the
.Rout.save file.)
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

bhs2 at mevik.net (Bj?rn-Helge Mevik) writes:

make check of R-alpha_2006-04-08_r37675 fails on Debian GNU/Linux 3.1 running
on an Intel P4 computer.

version
               _
platform       i686-pc-linux-gnu
arch           i686
os             linux-gnu
system         i686, linux-gnu
status         alpha
major          2
minor          3.0
year           2006
month          04
day            08
svn rev        37675
language       R
version.string Version 2.3.0 alpha (2006-04-08 r37675)

I'm using ATLAS with the SSE2 extensions, and get the same error with ATLAS
3.2.1 (packages atlas2-* 3.2.1ln-15 in Debian) and 3.6.0 (packages atlas3-*
3.6.0-19 in Debian).  I've also tried without external BLAS (--without-blas),
but the error still occurs.

43 (0) $ ./configure
[...]
R is now configured for i686-pc-linux-gnu

  Source directory:          .
  Installation directory:    /usr/local

  C compiler:                gcc  -g -O2 -std=gnu99
  Fortran 77 compiler:       g77  -g -O2

  C++ compiler:              g++  -g -O2
  Fortran 90/95 compiler:    g77 -g -O2

  Interfaces supported:      X11, tcltk
  External libraries:        readline, BLAS(ATLAS)
  Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS
  Options enabled:           R profiling

  Recommended packages:      yes

44 (0) $ make
[...]

45 (0) $ make check
[...]
running code in 'd-p-q-r-tests.R' ... OK
comparing 'd-p-q-r-tests.Rout' to './d-p-q-r-tests.Rout.save' ...777,778d776
< Warning message:
< full precision was not achieved in 'qbeta'
make[3]: *** [d-p-q-r-tests.Rout] Error 1
[...]

46 (0) $ diff tests/d-p-q-r-tests.Rout.{save,fail}
3c3
< Version 2.3.0 alpha (2006-04-03 r37628)
---
Version 2.3.0 alpha (2006-04-08 r37675)
791a792,793
Warning message:
full precision was not achieved in 'qbeta'
1073c1075
< Time elapsed:  2.53 0.03 2.55 0 0
---
Time elapsed:  4.939 0.024 4.967 0 0
The (hopefully) interesting part of tests/d-p-q-r-tests.Rout.fail:

## Check q*(p* ( log ), log) = identity
All.eq(Rbeta,   qbeta    (log(Pbeta), shape1 = .8, shape2 = 2, log=TRUE))
[1] TRUE
Warning message:
full precision was not achieved in 'qbeta'

Please let me know if there is more I can provide to help trace this!
I suspect that this is related to recent changes in the zero-finder,
and that it is relatively benign. (If it is the effect that I'm
thinking of, then the warning is spurious, and it is mainly a matter
of whether we want to try to get rid of the warning or update the
.Rout.save file.)
I am not seeing it on my platforms (FC3 x86_64 and i686 Linux with gcc 
3.4.5 and 4.1.0, i386 Windows and Solaris, with various compilers) and the 
zero-finder changes postdate r37675 (and qbeta does not use it). I think 
several other people are testing i686 Debian, including the daiuly CRAN 
package checks ....

I suspect it is a real (and long-standing) problem of loss of accuracy 
(2.2.1 did a check but did not report the results: it seems to be a 
convergence failure looking at qbeta.c).  What compiler version is this?

ATLAS is not involved.  You'll need to trace qbeta.c.
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 <ripley at stats.ox.ac.uk> writes:
  Source directory:          .
  Installation directory:    /usr/local

  C compiler:                gcc  -g -O2 -std=gnu99
  Fortran 77 compiler:       g77  -g -O2

  C++ compiler:              g++  -g -O2
  Fortran 90/95 compiler:    g77 -g -O2

  Interfaces supported:      X11, tcltk
  External libraries:        readline, BLAS(ATLAS)
  Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS
  Options enabled:           R profiling

  Recommended packages:      yes

44 (0) $ make
[...]

45 (0) $ make check
[...]
running code in 'd-p-q-r-tests.R' ... OK
comparing 'd-p-q-r-tests.Rout' to './d-p-q-r-tests.Rout.save' ...777,778d776
< Warning message:
< full precision was not achieved in 'qbeta'
make[3]: *** [d-p-q-r-tests.Rout] Error 1
[...]

46 (0) $ diff tests/d-p-q-r-tests.Rout.{save,fail}
3c3
< Version 2.3.0 alpha (2006-04-03 r37628)
---
Version 2.3.0 alpha (2006-04-08 r37675)
791a792,793
Warning message:
full precision was not achieved in 'qbeta'
1073c1075
< Time elapsed:  2.53 0.03 2.55 0 0
---
Time elapsed:  4.939 0.024 4.967 0 0
The (hopefully) interesting part of tests/d-p-q-r-tests.Rout.fail:

## Check q*(p* ( log ), log) = identity
All.eq(Rbeta,   qbeta    (log(Pbeta), shape1 = .8, shape2 = 2, log=TRUE))
[1] TRUE
Warning message:
full precision was not achieved in 'qbeta'

Please let me know if there is more I can provide to help trace this!
I suspect that this is related to recent changes in the zero-finder,
and that it is relatively benign. (If it is the effect that I'm
thinking of, then the warning is spurious, and it is mainly a matter
of whether we want to try to get rid of the warning or update the
.Rout.save file.)
I am not seeing it on my platforms (FC3 x86_64 and i686 Linux with gcc
3.4.5 and 4.1.0, i386 Windows and Solaris, with various compilers) and
the zero-finder changes postdate r37675 (and qbeta does not use it). I
think several other people are testing i686 Debian, including the
daiuly CRAN package checks ....

I suspect it is a real (and long-standing) problem of loss of accuracy
(2.2.1 did a check but did not report the results: it seems to be a
convergence failure looking at qbeta.c).  What compiler version is
this?

ATLAS is not involved.  You'll need to trace qbeta.c.
I don't see it with a current version either. What happens if you
reduce the optimization level? (I've tried both "-g" and -g "-O3").
Is that -std=gnu99 bit necessary?
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

I am not seeing it on my platforms (FC3 x86_64 and i686 Linux with gcc
3.4.5 and 4.1.0, i386 Windows and Solaris, with various compilers) and
the zero-finder changes postdate r37675 (and qbeta does not use it). I
think several other people are testing i686 Debian, including the
daiuly CRAN package checks ....

I suspect it is a real (and long-standing) problem of loss of accuracy
(2.2.1 did a check but did not report the results: it seems to be a
convergence failure looking at qbeta.c).  What compiler version is
this?
1 (0) $ gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Bj?rn-Helge Mevik

I don't see it with a current version either. What happens if you
reduce the optimization level? (I've tried both "-g" and -g "-O3").
Is that -std=gnu99 bit necessary?
My gcc is gcc (GCC) 3.3.5 (Debian 1:3.3.5-13).

I've now tried with ./configure CFLAGS="-g [-O|-O2|-O3] [-std=gnu99]",
i.e. with every combination from "-g" to "-g -O3 -std=gnu99".  The
error occured if and only if -O2 or -O3 was used.
Bj?rn-Helge Mevik
Since that compiler is not even the last in the 3.3.x series, and there 
are now three later (released) gcc series, I think we have to write that 
off to an optimization bug in gcc 3.3.x.

Peter Dalgaard wrote:

I don't see it with a current version either. What happens if you
reduce the optimization level? (I've tried both "-g" and -g "-O3").
Is that -std=gnu99 bit necessary?
(No, but it helps get fast C99 functions from the OS rather than slow 
substitutes.)
My gcc is gcc (GCC) 3.3.5 (Debian 1:3.3.5-13).

I've now tried with ./configure CFLAGS="-g [-O|-O2|-O3] [-std=gnu99]",
i.e. with every combination from "-g" to "-g -O3 -std=gnu99".  The
error occured if and only if -O2 or -O3 was used.

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
| Since that compiler is not even the last in the 3.3.x series, and there 
| are now three later (released) gcc series, I think we have to write that 
| off to an optimization bug in gcc 3.3.x.

Fair point, especially as you have to insist on using gcc 3.3.* on Debian:
-- 3.3.6 is the current 3.3.* one whereas Bj?rn-Helge used 3.3.5
-- 3.4.5 is the latest 3.* one supplanting 3.3.(5,6)
-- 4.0.3 is the current default
-- 4.1.0 is available too

That appears to be the same on Debian testing and unstable.

Dirk

edd at basebud:~> dpkg -l | grep gcc | cut -c -78
ii  gcc                               4.0.2-2                        The GNU C
ii  gcc-2.95                          2.95.4-22                      The GNU C
ii  gcc-3.3                           3.3.6-13                       The GNU C
ii  gcc-3.3-base                      3.3.6-13                       The GNU C
ii  gcc-3.4                           3.4.5-2                        The GNU C
ii  gcc-3.4-base                      3.4.5-2                        The GNU C
ii  gcc-4.0                           4.0.3-1                        The GNU C
ii  gcc-4.0-base                      4.0.3-1                        The GNU C
ii  gcc-4.1-base                      4.1.0-1                        The GNU C
ii  libgcc1                           4.1.0-1                        GCC suppo
edd at basebud:~>
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison

Fair point, especially as you have to insist on using gcc 3.3.* on Debian:
-- 3.3.6 is the current 3.3.* one whereas Bj?rn-Helge used 3.3.5
-- 3.4.5 is the latest 3.* one supplanting 3.3.(5,6)
-- 4.0.3 is the current default
-- 4.1.0 is available too

That appears to be the same on Debian testing and unstable.

Dirk

edd at basebud:~> dpkg -l | grep gcc | cut -c -78
ii  gcc                               4.0.2-2                        The GNU C
ii  gcc-2.95                          2.95.4-22                      The GNU C
ii  gcc-3.3                           3.3.6-13                       The GNU C
ii  gcc-3.3-base                      3.3.6-13                       The GNU C
ii  gcc-3.4                           3.4.5-2                        The GNU C
ii  gcc-3.4-base                      3.4.5-2                        The GNU C
ii  gcc-4.0                           4.0.3-1                        The GNU C
ii  gcc-4.0-base                      4.0.3-1                        The GNU C
ii  gcc-4.1-base                      4.1.0-1                        The GNU C
ii  libgcc1                           4.1.0-1                        GCC suppo
edd at basebud:~>
Hmmm... I don't `see' all those versions.  After an `aptitude update':

9 (1) $ aptitude search gcc
[...]
i   gcc                             - The GNU C compiler                       
i   gcc-2.95                        - The GNU C compiler                       
p   gcc-2.95-doc                    - Documentation for the GNU compilers (gcc,
v   gcc-3.0                         -                                          
v   gcc-3.0-base                    -                                          
v   gcc-3.0-doc                     -                                          
v   gcc-3.2                         -                                          
v   gcc-3.2-base                    -                                          
v   gcc-3.2-doc                     -                                          
i A gcc-3.3                         - The GNU C compiler                       
i A gcc-3.3-base                    - The GNU Compiler Collection (base package
p   gcc-3.3-doc                     - Documentation for the GNU compilers (gcc,
i   gcc-3.4                         - The GNU C compiler                       
i A gcc-3.4-base                    - The GNU Compiler Collection (base package
p   gcc-3.4-doc                     - Documentation for the GNU compilers (gcc,
[...]
The 3.3 is 3.3.5-13, and the 3.4 is 3.4.3-13.

My /etc/apt/sources.list is:

deb http://ftp.no.debian.org/debian/ sarge main non-free contrib
deb-src http://ftp.no.debian.org/debian/ sarge main non-free contrib
deb http://ftp.no.debian.org/debian-non-US sarge/non-US main contrib non-free
deb-src http://ftp.no.debian.org/debian-non-US sarge/non-US main contrib non-free
deb http://security.debian.org/ sarge/updates main contrib non-free

Why am I seeing older versions than you?

I just installed gcc-3.4, but gcc --version still says 3.3.5.  What
have I done (probably without knowing it) to `insist on using gcc
3.3.*', and how can I reverse that? (I have no desire to use old
compiler versions. :-)
Bj?rn-Helge Mevik
| 
| > Fair point, especially as you have to insist on using gcc 3.3.* on Debian:
| > -- 3.3.6 is the current 3.3.* one whereas Bj?rn-Helge used 3.3.5
| > -- 3.4.5 is the latest 3.* one supplanting 3.3.(5,6)
| > -- 4.0.3 is the current default
| > -- 4.1.0 is available too

[...]
| Hmmm... I don't `see' all those versions.  After an `aptitude update':

(That didn't show version numbers...)

| My /etc/apt/sources.list is:
| 
| deb http://ftp.no.debian.org/debian/ sarge main non-free contrib
| deb-src http://ftp.no.debian.org/debian/ sarge main non-free contrib
| deb http://ftp.no.debian.org/debian-non-US sarge/non-US main contrib non-free
| deb-src http://ftp.no.debian.org/debian-non-US sarge/non-US main contrib non-free
| deb http://security.debian.org/ sarge/updates main contrib non-free
| 
| Why am I seeing older versions than you?

Because you point to 'sarge' which was frozen and released a year ago.
If you want something newer than Debian stable, you have to point to it.

This is all off-topic here. Please consider (subscribing and) posting to
r-sig-debian for R/Debian related matters, or debian-help for generic Debian
questions. 

Hope this helps, Dirk
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison
Uwe Ligges had the same problem with gcc 3.3.1 on SuSE 9.0.  So I 
installed gcc 3.3.5 from the sources on an i386 box, and was able to 
reproduce it.

It is an optimization bug.  The crucial code is

 	xtrunc = tx;	/* this prevents trouble with excess FPU */
 				/* precision on some machines. */
 	if (xtrunc == xinbta)
 	    goto L_converged;

and both xtrunc and xinbta are volatile.  Seems that is being ignored in 
3.3.5/1, and so the loop never terminates.

Using an explicit check is safer and faster. I'll put mine in once I have 
finished testing.

On 10 April 2006 at 14:31, Bj?rn-Helge Mevik wrote:
| Dirk Eddelbuettel wrote:
|
| > Fair point, especially as you have to insist on using gcc 3.3.* on Debian:
| > -- 3.3.6 is the current 3.3.* one whereas Bj?rn-Helge used 3.3.5
| > -- 3.4.5 is the latest 3.* one supplanting 3.3.(5,6)
| > -- 4.0.3 is the current default
| > -- 4.1.0 is available too

[...]
| Hmmm... I don't `see' all those versions.  After an `aptitude update':

(That didn't show version numbers...)

| My /etc/apt/sources.list is:
|
| deb http://ftp.no.debian.org/debian/ sarge main non-free contrib
| deb-src http://ftp.no.debian.org/debian/ sarge main non-free contrib
| deb http://ftp.no.debian.org/debian-non-US sarge/non-US main contrib non-free
| deb-src http://ftp.no.debian.org/debian-non-US sarge/non-US main contrib non-free
| deb http://security.debian.org/ sarge/updates main contrib non-free
|
| Why am I seeing older versions than you?

Because you point to 'sarge' which was frozen and released a year ago.
If you want something newer than Debian stable, you have to point to it.

This is all off-topic here. Please consider (subscribing and) posting to
r-sig-debian for R/Debian related matters, or debian-help for generic Debian
questions.

Hope this helps, Dirk

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 <ripley at stats.ox.ac.uk> writes:
Uwe Ligges had the same problem with gcc 3.3.1 on SuSE 9.0.  So I
installed gcc 3.3.5 from the sources on an i386 box, and was able to
reproduce it.

It is an optimization bug.  The crucial code is

 	xtrunc = tx;	/* this prevents trouble with excess FPU */
 				/* precision on some machines. */
 	if (xtrunc == xinbta)
 	    goto L_converged;

and both xtrunc and xinbta are volatile.  Seems that is being ignored
in 3.3.5/1, and so the loop never terminates.

Using an explicit check is safer and faster. I'll put mine in once I
have finished testing.
However, if the compiler is disobeying "volatile", it is buggy and it
might be safer not to use that compiler at all. There's no telling
what else might break for the same reason.
On Mon, 10 Apr 2006, Dirk Eddelbuettel wrote:

On 10 April 2006 at 14:31, Bj?rn-Helge Mevik wrote:
| Dirk Eddelbuettel wrote:
|
| > Fair point, especially as you have to insist on using gcc 3.3.* on Debian:
| > -- 3.3.6 is the current 3.3.* one whereas Bj?rn-Helge used 3.3.5
| > -- 3.4.5 is the latest 3.* one supplanting 3.3.(5,6)
| > -- 4.0.3 is the current default
| > -- 4.1.0 is available too

[...]
| Hmmm... I don't `see' all those versions.  After an `aptitude update':

(That didn't show version numbers...)

| My /etc/apt/sources.list is:
|
| deb http://ftp.no.debian.org/debian/ sarge main non-free contrib
| deb-src http://ftp.no.debian.org/debian/ sarge main non-free contrib
| deb http://ftp.no.debian.org/debian-non-US sarge/non-US main contrib non-free
| deb-src http://ftp.no.debian.org/debian-non-US sarge/non-US main contrib non-free
| deb http://security.debian.org/ sarge/updates main contrib non-free
|
| Why am I seeing older versions than you?

Because you point to 'sarge' which was frozen and released a year ago.
If you want something newer than Debian stable, you have to point to it.

This is all off-topic here. Please consider (subscribing and) posting to
r-sig-debian for R/Debian related matters, or debian-help for generic Debian
questions.

Hope this helps, Dirk

-- 
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______________________________________________
R-devel at r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

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

Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:

Uwe Ligges had the same problem with gcc 3.3.1 on SuSE 9.0.  So I
installed gcc 3.3.5 from the sources on an i386 box, and was able to
reproduce it.

It is an optimization bug.  The crucial code is

 	xtrunc = tx;	/* this prevents trouble with excess FPU */
 				/* precision on some machines. */
 	if (xtrunc == xinbta)
 	    goto L_converged;

and both xtrunc and xinbta are volatile.  Seems that is being ignored
in 3.3.5/1, and so the loop never terminates.

Using an explicit check is safer and faster. I'll put mine in once I
have finished testing.
However, if the compiler is disobeying "volatile", it is buggy and it
might be safer not to use that compiler at all. There's no telling
what else might break for the same reason.
I agree, and in my earlier reply suggested we write this off but given we 
now have two reports I can see many more after release.  It is a known bug 
in gcc 3.3.x, and so far nothing else has come to light.  (This only came 
to light because the warning had previously been suppressed.)

I would advise against systems as old as SuSE 9.0 or many grounds, but
some people may have no choice.

[...]
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