Bugzilla Bug 167860

Is sci-libs/gsl-1.8 ready for stabilization?
Do you know of any problem with other programs?

Hi Torsten,

I am not aware of any problems and from my point of view gsl-1.8 should
be good to go stable. I'll have a look at it soon and if things are fine I'll
cc the respective arch teams. 

Thanks,
Markus

Hi,

Could we please stabilize sci-libs/gsl-1.8!?
It has been bug free for quite some time now and seems
to be doing pretty well :)
src_test() will go through a fairly extensive set of
test routines and should allow you to verify the package.

Thanks,
Markus

Stable for HPPA.

x86 stable

are the tests 64bit save? (this is ppc64)

[...]
make[2]: Entering directory
`/var/tmp/portage/sci-libs/gsl-1.8/work/gsl-1.8/ieee-utils'
FAIL: double x = -1.3304..., mantissa
(0101100010000010010100101010010010001000100011101110 observed vs
0101010010010010010100101010010010001000100011101110 expected) [149]
FAIL: double x = 3.37e297, mantissa
(0100011001111001100101111001100000100110011101000100 observed vs
0100100111001001100101111001100000100110011101000100 expected) [153]
FAIL: double x = 3.37e-297, mantissa
(0001000100111011101011100001110010100001001100110111 observed vs
0001101000011011101011100001110010100001001100110111 expected) [157]
FAIL: double x = DBL_MIN/2^5, mantissa
(0000000000000000000000000000000000000000000000000000 observed vs
0000100000000000000000000000000000000000000000000000 expected) [185]
FAIL: double x = DBL_MIN/2^5, type is DENORMAL (5 observed vs 4 expected) [186]
FAIL: double x = DBL_MIN/2^6, mantissa
(0000000000000000000000000000000000000000000000000000 observed vs
0000010000000000000000000000000000000000000000000000 expected) [189]
FAIL: double x = DBL_MIN/2^6, type is DENORMAL (5 observed vs 4 expected) [190]
FAIL: double x = DBL_MIN/2^7, mantissa
(0000000000000000000000000000000000000000000000000000 observed vs
0000001000000000000000000000000000000000000000000000 expected) [193]
FAIL: double x = DBL_MIN/2^7, type is DENORMAL (5 observed vs 4 expected) [194]
FAIL: double x = DBL_MIN/2^8, mantissa
(0000000000000000000000000000000000000000000000000000 observed vs
0000000100000000000000000000000000000000000000000000 expected) [197]
FAIL: double x = DBL_MIN/2^8, type is DENORMAL (5 observed vs 4 expected) [198]
FAIL: double x = DBL_MIN/2^9, mantissa
(0000000000000000000000000000000000000000000000000000 observed vs
0000000010000000000000000000000000000000000000000000 expected) [201]
FAIL: double x = DBL_MIN/2^9, type is DENORMAL (5 observed vs 4 expected) [202]
FAIL: double x = DBL_MIN/2^10, mantissa
(0000000000000000000000000000000000000000000000000000 observed vs
0000000001000000000000000000000000000000000000000000 expected) [205]
FAIL: double x = DBL_MIN/2^10, type is DENORMAL (5 observed vs 4 expected)
[206]
FAIL: double x = DBL_MIN/2^11, mantissa
(0000000000000000000000000000000000000000000000000000 observed vs
0000000000100000000000000000000000000000000000000000 expected) [209]
FAIL: double x = DBL_MIN/2^11, type is DENORMAL (5 observed vs 4 expected)
[210]
FAIL: double x = DBL_MIN/2^12, mantissa
(0000000000000000000000000000000000000000000000000000 observed vs
0000000000010000000000000000000000000000000000000000 expected) [213]
FAIL: double x = DBL_MIN/2^12, type is DENORMAL (5 observed vs 4 expected)
[214]
FAIL: double x = DBL_MIN/2^37, mantissa
(0000100000000000000000000000000000001000000000000000 observed vs
0000000000000000000000000000000000001000000000000000 expected) [313]
FAIL: double x = DBL_MIN/2^38, mantissa
(0000010000000000000000000000000000000100000000000000 observed vs
0000000000000000000000000000000000000100000000000000 expected) [317]
FAIL: double x = DBL_MIN/2^39, mantissa
(0000001000000000000000000000000000000010000000000000 observed vs
0000000000000000000000000000000000000010000000000000 expected) [321]
FAIL: double x = DBL_MIN/2^40, mantissa
(0000000100000000000000000000000000000001000000000000 observed vs
0000000000000000000000000000000000000001000000000000 expected) [325]
FAIL: double x = DBL_MIN/2^41, mantissa
(0000000010000000000000000000000000000000100000000000 observed vs
0000000000000000000000000000000000000000100000000000 expected) [329]
FAIL: double x = DBL_MIN/2^42, mantissa
(0000000001000000000000000000000000000000010000000000 observed vs
0000000000000000000000000000000000000000010000000000 expected) [333]
FAIL: double x = DBL_MIN/2^43, mantissa
(0000000000100000000000000000000000000000001000000000 observed vs
0000000000000000000000000000000000000000001000000000 expected) [337]
FAIL: double x = DBL_MIN/2^44, mantissa
(0000000000010000000000000000000000000000000100000000 observed vs
0000000000000000000000000000000000000000000100000000 expected) [341]
FAIL: test
===================
1 of 1 tests failed
===================

(In reply to comment #5)
> are the tests 64bit save? (this is ppc64)
> 

I assumed so since nothing (significant) has changed in this part
of gsl from 1.7 which is stable on ppc64 and presumably
passed the tests. That said, could you please try gsl-1.7
and see if this works for you. 

Also, during configure, could you check for output 
similar to 

------ SNIP ------------------

checking for IEEE arithmetic interface type... gnux86
checking for FPU_SETCW... yes
checking for IEEE compiler flags... none
checking for IEEE comparisons... yes
checking for IEEE denormalized values... yes

---------------------------------

I would assume you should see gnuppc instead of gnux86
otherwise gsl might select improper IEEE conventions
for its floating point operations.

Thanks,
Markus

(In reply to comment #6)
> (In reply to comment #5)
> > are the tests 64bit save? (this is ppc64)
> > 
> 
> I assumed so since nothing (significant) has changed in this part
> of gsl from 1.7 which is stable on ppc64 and presumably
> passed the tests. That said, could you please try gsl-1.7
> and see if this works for you. 

not necessarily ... (that's due to /me forgetting to enable FEATURES="test"
after some merges, which are known to fail tests - for example some parts of
kde ..)

1.7 does fail, too.

> Also, during configure, could you check for output 
> similar to 
> 
> ------ SNIP ------------------
> 
> checking for IEEE arithmetic interface type... gnux86
> checking for FPU_SETCW... yes
> checking for IEEE compiler flags... none
> checking for IEEE comparisons... yes
> checking for IEEE denormalized values... yes
> 
> ---------------------------------
> 
> I would assume you should see gnuppc instead of gnux86
> otherwise gsl might select improper IEEE conventions
> for its floating point operations.

I'm getting this:

checking for IEEE arithmetic interface type... unknown
checking for IEEE compiler flags... none
checking for IEEE comparisons... yes
checking for IEEE denormalized values... yes


I'll mark 1.8 stable on ppc64 once cvs is up again as this is no regression.
I'll open an upstream bug for this, so this is fixed in future versions. I
should have never marked 1.7 stable... :-/

(In reply to comment #7)
> 
> checking for IEEE arithmetic interface type... unknown
> checking for IEEE compiler flags... none
> checking for IEEE comparisons... yes
> checking for IEEE denormalized values... yes
> 
> 

Thanks a lot for your efforts,  Markus!
I apologize for my "ppc ignorance" but what would
the proper $host in configure be for ppc/ppc64?
Currently, gsl's configure checks for powerpc-*-linux* which
is obviously incorrect.

Thanks,
Markus 

the correct CHOST is powerpc64*-*-linux*. Unfortunately you cannot use gnuppc
as IEEE arithmetic interface type. (tests still fail if I change configure to
detect my machine as gnuppc).

I've marked gsl 1.8 stable on ppc64 (as 1.7 has the same issues on ppc64).

As I said before I'll make this problem known to upstream. The tests don't look
too difficult so I think I can create a proper patch.

(In reply to comment #9) I've marked gsl 1.8 stable on ppc64 (as 1.7 has the
same issues on ppc64).
> 
> As I said before I'll make this problem known to upstream. The tests don't look
> too difficult so I think I can create a proper patch.
> 

Thanks :)

Stable on ppc

amd64 stable

ia64 stable

ppc-macos moved to prefix.

Hi alpha and arm herd,

I am going to close this stabilization bug since I will
open a new one for gsl-1.9 shortly which we then 
can hopefully mark stable on your
respective arches. I hope this works for you
and I am closing this as fixed anyway.

cheers,
Markus