On Fri, Aug 28, 2020 at 9:47 PM Patrick Alken
<patrick.alken@colorado.edu> wrote:

>
> Hello, I just committed a fix to the git repository. Would you be able
> to test the git version to see if its resolved on your platform?

Hi Patrick.

Here's the result for the tip of master:

make  check-TESTS
make[2]: Entering directory '/home/jwalton/Build-Scripts/gsl-2.6/specfunc'
make[3]: Entering directory '/home/jwalton/Build-Scripts/gsl-2.6/specfunc'
FAIL: test
============================================================================
Testsuite summary for gsl 2.6+
============================================================================
# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0
============================================================================
See specfunc/test-suite.log
============================================================================

$ cat gsl-2.6/specfunc/test-suite.log
=======================================
   gsl 2.6+: specfunc/test-suite.log
=======================================

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test
==========

FAIL: res[60]+0.0 [2351]
  expected: 6.7753780053831863e+71
  obtained: 6.7753780053832010e+71
  fracdiff: 1.0856927230202910e-15
  value not within tolerance of expected value
  6.775378005383201023e+71
FAIL: res[100]+0.0 [2353]
  expected: 2.9579660004912027e+118
  obtained: 2.9579660004911946e+118
  fracdiff: 1.3629435007875587e-15
  value not within tolerance of expected value
  2.957966000491194605e+118
FAIL: gsl_sf_hermite_array_deriv(23, 100, 0.75) [2354]
FAIL: Hermite Functions [2498]
FAIL: gsl_sf_laguerre_n_e(1e6+1, 2.5, 2.5, &r) [2991]
  expected: -4.8017961545391276e+05
  obtained: -4.8017961546181823e+05 ± 3.6891004271829821e-02 (rel=7.68275e-08)
  fracdiff: 8.2317878690294596e-12
 tolerance: 3.6379788070917130e-12
  value not within tolerance of expected value
  -4.801796154618182336e+05  3.689100427182982062e-02
FAIL: Laguerre Polynomials [3030]
FAIL test (exit status: 1)

==========

On Fri, Aug 28, 2020 at 9:47 PM Patrick Alken
<patrick.alken@colorado.edu> wrote:

>
> Hello, I just committed a fix to the git repository. Would you be able
> to test the git version to see if it's resolved on your platform?

My bad... I should have built with 'make -k' to get back to the spmatrix test...

Here is the result of master for spmatrix. Things have improved:

$ cat gsl-2.6/spmatrix/test-suite.log
=======================================
   gsl 2.6+: spmatrix/test-suite.log
=======================================

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test
==========

FAIL: gsl_spmatrix_complex_float_scale[53,107](COO) [21671]
FAIL: gsl_spmatrix_complex_float_scale[53,107](CSC) [28476]
FAIL: gsl_spmatrix_complex_float_scale[53,107](CSR) [35281]
FAIL: gsl_spmatrix_complex_float_scale[40,20](COO) [65775]
FAIL: gsl_spmatrix_complex_float_scale[40,20](CSC) [66416]
FAIL: gsl_spmatrix_complex_float_scale[40,20](CSR) [67057]
FAIL: gsl_spmatrix_complex_float_scale[30,30](COO) [76375]
FAIL: gsl_spmatrix_complex_float_scale[30,30](CSC) [78176]
FAIL: gsl_spmatrix_complex_float_scale[30,30](CSR) [79977]
FAIL test (exit status: 1)

I see the same results when I backport 76f5f97e3389 to the GSL 2.6 tarball.

Attached are the test-suite logs from a 'make -k' from master. All of
the test results should be present.

Jeff


==============

Hi Everyone/Patrick,

A quick note since I'm making a testing pass on GSL...

Ubuntu 18.04 LTS x86_64 (fully patched) fails to link out of the box
due to a missing -lm. The symptom is undefined references for symbols
like sincos.

It may be a good idea to add an Autoconf test for:

• -lm, to avoid the link error on Linux
• -Wl,--as-needed to discard unneeded libraries

-lm goes in LIBS, and -Wl,--as-needed goes in AM_CFLAGS when available.

Autoconf will probably be the best in this case since -lm may be
missing on the target platform. I'm not sure how AIX, BSDs, OS X and
Solaris are going to act. I have not gotten that far in testing.

Jeff


==============

Hi Everyone/Patrick,

A quick testing pass with CFLAGS that include '-fsanitize=undefined
-fno-sanitize-recover=all' shows some undefined behavior in the
library or test suite. Several of them are listed below.

Some of them, like "runtime error: left shift of 1 by 31 places cannot
be represented in type 'int'...", are easy to fix. Just use "1U << 31"
since unsigned types do not suffer overflow. Unsigned types can wrap,
but that's well defined behavior in C/C++.

Jeff

====================

$ cat gsl-2.6/sys/test-suite.log
...
pow_int.c:34:10: runtime error: negation of -2147483648 cannot be
represented in type 'int'; cast to an unsigned type to negate this
value to itself
FAIL test (exit status: 1)

====================

$ cat gsl-2.6/specfunc/test-suite.log
...
FAIL: res[60]+0.0 [2351]
  expected: 6.7753780053831863e+71
  obtained: 6.7753780053832010e+71
  fracdiff: 1.0856927230202910e-15
  value not within tolerance of expected value
  6.775378005383201023e+71
FAIL: res[100]+0.0 [2353]
  expected: 2.9579660004912027e+118
  obtained: 2.9579660004911946e+118
  fracdiff: 1.3629435007875587e-15
  value not within tolerance of expected value
  2.957966000491194605e+118
FAIL: gsl_sf_hermite_array_deriv(23, 100, 0.75) [2354]
hermite.c:470:34: runtime error: signed integer overflow: 100028 *
100028 cannot be represented in type 'int'

====================

$ cat gsl-2.6/rng/test-suite.log
...
random.c:126:9: runtime error: signed integer overflow:
1508052306957066566 + 7775806152332120189 cannot be represented in
type 'long int'
FAIL test (exit status: 1)

====================

$ cat gsl-2.6/randist/test-suite.log
...
test.c:861:45: runtime error: left shift of 1 by 31 places cannot be
represented in type 'int'
FAIL test (exit status: 1)

====================

$ cat gsl-2.6/multifit_nlinear/test-suite.log
...
trs = levenberg-marquardt
solver = cholesky
solver = mcholesky
solver = qr
solver = svd
trs = levenberg-marquardt+accel
solver = cholesky
solver = mcholesky
solver = qr
solver = svd
trs = dogleg
solver = mcholesky
nielsen.c:98:7: runtime error: left shift of 4611686018427387904 by 1
places cannot be represented in type 'long int'
FAIL test (exit status: 1)

==================

Hi Everyone/Patrick,

A quick testing pass with CFLAGS that include '-fsanitize=address'
shows some memory errors in the library or test suite.

It appears to be limited to matrix class and testing.

=====================================
$ cat gsl-2.6/matrix/test-suite.log
...
==7058==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f59e568ab40 in __interceptor_malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x556e12fc4a63 in gsl_vector_complex_alloc
/home/jwalton/Build-Scripts/gsl-2.6/vector/init_source.c:26
    #2 0x556e12eff45d in test_complex_ops
/home/jwalton/Build-Scripts/gsl-2.6/matrix/test_complex_source.c:753
    #3 0x556e12ef4ab8 in main
/home/jwalton/Build-Scripts/gsl-2.6/matrix/test.c:187
    #4 0x7f59e4bd6b96 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Direct leak of 40 byte(s) in 1 object(s) allocated from:
    #0 0x7f59e568ab40 in __interceptor_malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
    #1 0x556e12fc40d3 in gsl_vector_complex_long_double_alloc
/home/jwalton/Build-Scripts/gsl-2.6/vector/init_source.c:26
    #2 0x556e12ef92bf in test_complex_long_double_ops
/home/jwalton/Build-Scripts/gsl-2.6/matrix/test_complex_source.c:716
    #3 0x556e12ef4ad6 in main
/home/jwalton/Build-Scripts/gsl-2.6/matrix/test.c:189
    #4 0x7f59e4bd6b96 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
...


==================

Hi Everyone/Patrick,

I'm building GSL master on Ubuntu 18.04.5 LTS i686 (fully patched).
The rub is, it is real 32-bit iron. It's an old Pentium III machine.

This looks like a new failure that's only present on 32-bit machines:

$ cat gsl-2.6/linalg/test-suite.log
====================================
   gsl 2.6: linalg/test-suite.log
====================================

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

FAIL: test
==========

FAIL: LU_decomp rect3: ( 80,100)[64,65]: 4.12655062968342833e-05
4.12655062973499298e-05
 (4.12655062968342833e-05 observed vs 4.12655062973499298e-05
expected) [5515924]
FAIL: cholesky_decomp unscaled random: (147,147)[92,130]:
1.06636434789185456e-07   1.0663643479347229e-07
 (1.06636434789185456e-07 observed vs 1.0663643479347229e-07 expected)
[12196119]
FAIL: cholesky_decomp unscaled random: (147,147)[130,92]:
1.06636434789185456e-07   1.0663643479347229e-07
 (1.06636434789185456e-07 observed vs 1.0663643479347229e-07 expected)
[12201667]
FAIL: cholesky_decomp scaled random: (147,147)[92,130]:
1.06636434797499932e-07   1.0663643479347229e-07
 (1.06636434797499932e-07 observed vs 1.0663643479347229e-07 expected)
[12217728]
FAIL: cholesky_decomp scaled random: (147,147)[130,92]:
1.06636434797499932e-07   1.0663643479347229e-07
 (1.06636434797499932e-07 observed vs 1.0663643479347229e-07 expected)
[12223276]

I can send over full logs, if needed/wanted. But I am guessing you can
probably duplicate it locally on a 32-bit machine or vm.

When I encounter 32-bit machine failures, I find it helpful to run
UBsan. UBsan can sometimes pinpoint where size assumptions are made,
like a long being 64-bits (an initialization will fail) or overflows
on calculations.

Jeff