gsl 1.2.90 release candidate : two failures

gsl 1.2.90 release candidate : two failures

[Luc Maisonobe]

Hello,

I just checked gsl 1.290 relase candidate on an old sparc ultra 5 with
solaris 2.8 and gcc 3.2.1 (using the native assembler and linker of the
system).

I get two failures (on the same function) :

FAIL: gsl_vector_complex_float_swap_elements exchanges elements
correctly

FAIL: gsl_vector_complex_float_swap_elements (static) exchanges elements
correctly

The message is misleading, is it really a failure ?

                                                          Luc

Re: gsl 1.2.90 release candidate : two failures

[Brian Gough]

Luc Maisonobe writes:
 > Hello,
 >  I just checked gsl 1.290 relase candidate on an old sparc ultra 5
 > with solaris 2.8 and gcc 3.2.1 (using the native assembler and
 > linker of the system).
 >  I get two failures (on the same function) :
 >  FAIL: gsl_vector_complex_float_swap_elements exchanges elements
 > correctly
 >  FAIL: gsl_vector_complex_float_swap_elements (static) exchanges
 > elements correctly
 >  The message is misleading, is it really a failure ?

Thanks. It is a failure (the FAIL: is the definitive result).
Stepping through with the debugger might show why.

Brian

Re: gsl 1.2.90 release candidate : two failures

[Philip Kendall]

On Fri, Dec 13, 2002 at 08:48:09AM -0600, Rodney Sparapani wrote:
> Luc:
> 
> Very interesting.  I'm setup very similarly.  The only minor differences is that 
> I'm using a newer ultra-sparc with GCC 3.2 and I don't get those failures, but I 
> do get:
> 
> from test and test_static
> FAIL: gsl_vector_long_double_div divides correctly

I can also replicate this, on

cass30:pak:~/data2/gsl-1.2.90/vector$ uname -a
SunOS cass30 5.8 Generic_108528-16 sun4u sparc SUNW,Ultra-4

with

cass30:pak:~/data2/gsl-1.2.90/vector$ gcc --version
gcc (GCC) 3.1

It appears to me to be a gcc optimisation problem; I added a quick
debugging printf in before line 267 of vector/test_source.c and then
compiled (only) test_static without optimisation, and obtained:

<snip test passes up to this point>

r=1 x=3 y=3 z=1 fabs(r-z)=0 tolerance=2.38419e-07
r=0.8 x=4 y=5 z=0.8 fabs(r-z)=0 tolerance=1.90735e-07
r=0.714286 x=5 y=7 z=0.714286 fabs(r-z)=0 tolerance=1.70299e-07
r=0.666667 x=6 y=9 z=0.666667 fabs(r-z)=0 tolerance=1.58946e-07
r=0.636364 x=7 y=11 z=0.636364 fabs(r-z)=0 tolerance=1.51721e-07
r=0.615385 x=8 y=13 z=0.615385 fabs(r-z)=0 tolerance=1.46719e-07

<snip lots of sane results>

r=0.500733 x=1024 y=2045 z=0.500733 fabs(r-z)=0 tolerance=1.19384e-07
r=0.500733 x=1025 y=2047 z=0.500733 fabs(r-z)=0 tolerance=1.19384e-07
r=0.500732 x=1026 y=2049 z=0.500732 fabs(r-z)=0 tolerance=1.19384e-07
r=0.500731 x=1027 y=2051 z=0.500731 fabs(r-z)=0 tolerance=1.19384e-07
r=0.500731 x=1028 y=2053 z=0.500731 fabs(r-z)=0 tolerance=1.19383e-07
r=0.50073 x=1029 y=2055 z=0.50073 fabs(r-z)=0 tolerance=1.19383e-07
PASS: gsl_vector_div divides correctly

However, if test_static is compiled with optimisation (-O1 is sufficient
to trigger this), I get:

r=-2.17498e+307 x=-2.17502e+307 y=1 z=2.38419e-07 fabs(r-z)=7.66007e-309 tolerance=2.38419e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.8 z=1.90735e-07 fabs(r-z)=7.66007e-309 tolerance=1.90735e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.714286 z=1.70299e-07 fabs(r-z)=7.66007e-309 tolerance=1.70299e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.666667 z=1.58946e-07 fabs(r-z)=7.66007e-309 tolerance=1.58946e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.636364 z=1.51721e-07 fabs(r-z)=7.66007e-309 tolerance=1.51721e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.615385 z=1.46719e-07 fabs(r-z)=7.66007e-309 tolerance=1.46719e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.6 z=1.43051e-07 fabs(r-z)=7.66007e-309 toler
ance=1.43051e-07

<snip lots more of the same>

r=-2.17498e+307 x=-2.17502e+307 y=0.500733 z=1.19384e-07 fabs(r-z)=7.66007e-309 tolerance=1.19384e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.500733 z=1.19384e-07 fabs(r-z)=7.66007e-309 tolerance=1.19384e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.500732 z=1.19384e-07 fabs(r-z)=7.66007e-309 tolerance=1.19384e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.500731 z=1.19384e-07 fabs(r-z)=7.66007e-309 tolerance=1.19384e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.500731 z=1.19383e-07 fabs(r-z)=7.66007e-309 tolerance=1.19383e-07
r=-2.17498e+307 x=-2.17502e+307 y=0.50073 z=1.19383e-07 fabs(r-z)=7.66007e-309 tolerance=1.19383e-07
FAIL: gsl_vector_long_double_div divides correctly

HTH (somewhat),

Phil

-- 
"Rules of combat older than contact with other races. Did not mention
aliens. Rules change caught up in committee. Not come through yet."
	          Former Green Leader: Babylon 5: The Geometry of Shadows

Re: gsl 1.2.90 release candidate : two failures

[Rodney Sparapani]

Luc:

Very interesting.  I'm setup very similarly.  The only minor differences is that 
I'm using a newer ultra-sparc with GCC 3.2 and I don't get those failures, but I 
do get:

from test and test_static
FAIL: gsl_vector_long_double_div divides correctly

Rodney

>Date: Thu, 12 Dec 2002 15:07:05 +0100
>From: Luc Maisonobe <Luc.Maisonobe@c-s.fr>
>MIME-Version: 1.0
>To: gsl-discuss@sources.redhat.com
>Subject: gsl 1.2.90 release candidate : two failures
>Content-Transfer-Encoding: 7bit
>
>Hello,
>
>I just checked gsl 1.290 relase candidate on an old sparc ultra 5 with
>solaris 2.8 and gcc 3.2.1 (using the native assembler and linker of the
>system).
>
>I get two failures (on the same function) :
>
>FAIL: gsl_vector_complex_float_swap_elements exchanges elements
>correctly
>
>FAIL: gsl_vector_complex_float_swap_elements (static) exchanges elements
>correctly
>
>The message is misleading, is it really a failure ?
>
>                                                          Luc

Rodney Sparapani              Medical College of Wisconsin
Sr. Biostatistician           Patient Care & Outcomes Research
rsparapa@mcw.edu              http://www.mcw.edu/pcor
Was 'Name That Tune' rigged?  WWLD -- What Would Lombardi Do