Bug 423908 - s390x false positives running make auxchecks (gsl tests)
Summary: s390x false positives running make auxchecks (gsl tests)
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Andreas Arnez
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-05 16:39 UTC by Mark Wielaard
Modified: 2024-10-14 05:53 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Possible fix for the GSL build issues (2.19 KB, patch)
2024-10-01 15:30 UTC, Andreas Arnez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Wielaard 2020-07-05 16:39:25 UTC
Running make auxchecks on current git will run the GNU Scientific Library testsuite under valgrind memcheck. Currently it produces false positives on s390x:

==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x1005E12: compare_complex_float_results (compare_source.c:38)
==9580==    by 0x1005E12: test_complex_float_func (test_complex_source.c:108)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x100565C: compare_complex_float_results (compare_source.c:38)
==9580==    by 0x100565C: test_complex_float_func (test_complex_source.c:128)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x1005670: compare_complex_float_results (compare_source.c:44)
==9580==    by 0x1005670: test_complex_float_func (test_complex_source.c:128)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x10054A2: compare_complex_float_results (compare_source.c:38)
==9580==    by 0x10054A2: test_complex_float_func (test_complex_source.c:155)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x10054B6: compare_complex_float_results (compare_source.c:44)
==9580==    by 0x10054B6: test_complex_float_func (test_complex_source.c:155)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x1005D50: compare_complex_float_results (compare_source.c:38)
==9580==    by 0x1005D50: test_complex_float_func (test_complex_source.c:181)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x1005CF4: compare_complex_float_results (compare_source.c:38)
==9580==    by 0x1005CF4: test_complex_float_func (test_complex_source.c:196)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x1005B8A: compare_complex_float_results (compare_source.c:38)
==9580==    by 0x1005B8A: test_complex_float_func (test_complex_source.c:213)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x1005A80: compare_complex_float_results (compare_source.c:44)
==9580==    by 0x1005A80: test_complex_float_func (test_complex_source.c:213)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x1005E26: compare_complex_float_results (compare_source.c:44)
==9580==    by 0x1005E26: test_complex_float_func (test_complex_source.c:108)
==9580==    by 0x1000DE1: main (test.c:108)
==9580== 
==9580== Conditional jump or move depends on uninitialised value(s)
==9580==    at 0x1005860: compare_complex_float_results (compare_source.c:44)
==9580==    by 0x1005860: test_complex_float_func (test_complex_source.c:181)
==9580==    by 0x1000DE1: main (test.c:108)
==9580==
Comment 1 Florian Krohm 2024-09-28 18:50:49 UTC
I just ran it with current git d224730c8861a1ac2578bcbcaf2f704f56257134 and do not see any valgrind errors in valgrind-gsl.out
Machine: z15 (8561)
gcc: gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Comment 2 Andreas Arnez 2024-10-01 15:17:46 UTC
I just tried with current upstream and can't reproduce this either.  I'm running on a z16 with Fedora 40.
However, I'm having some trouble with this test case.  In my testing gsl-1.6 doesn't even compile as-is:

make auxchecks
...
.../eigen/jacobi.c: In function ‘gsl_eigen_invert_jacobi’:
.../eigen/jacobi.c:227:57: error: passing argument 5 of ‘gsl_eigen_jacobi’ from incompatible pointer type [-Wincompatible-pointer-types]
  227 |     status = gsl_eigen_jacobi(tmp, eval, evec, max_rot, &nrot);
...
make[4]: *** [Makefile:614: jacobi.lo] Error 1

Also, gsl's configure.ac has an issue with the checks for IEEE comparisons and for IEEE denormalized values. These checks fail on my system because their test programs don't compile. They call exit() without declaring it.

After fixing these issues (I'll attach a patch for that), I seem to get more failures in the test suite than expected:

FAIL: random-bsd, 10000 steps (1439263323 observed vs 1457025928 expected)
FAIL: random32-bsd, 10000 steps (626977143 observed vs 1663114331 expected)
FAIL: random64-bsd, 10000 steps (1262850638 observed vs 864469165 expected)
FAIL: random128-bsd, 10000 steps (1439263323 observed vs 1457025928 expected)
FAIL: random256-bsd, 10000 steps (2064015170 observed vs 1216357476 expected)
FAIL: random-libc5, 10000 steps (60563615 observed vs 428084942 expected)
FAIL: random32-libc5, 10000 steps (827587933 observed vs 1967452027 expected)
FAIL: random64-libc5, 10000 steps (963916554 observed vs 2106639801 expected)
FAIL: random128-libc5, 10000 steps (60563615 observed vs 428084942 expected)
FAIL: random256-libc5, 10000 steps (799840090 observed vs 116367984 expected)

And one failure less than on x86:
-FAIL: qawo(f456) elist (7.25063790881233303e-15 observed vs 7.25922435194575979e-15 expected)

And while the following doesn't seem to cause an error, I'm not sure if it's intentional:

.../cdf/test.c: In function ‘test_ugaussian’:
.../cdf/test.c:121:3: warning: floating constant truncated to zero [-Woverflow]
  121 |   TEST (gsl_cdf_ugaussian_P, (-40.0), 3.655893540915029703748985850e-350, TEST_TOL3);

with the same warning repeating in line 133.

In any case, I don't see the memcheck diagnostics from comment 0.  I haven't investigated the cause for the rng test failures yet.
Comment 3 Andreas Arnez 2024-10-01 15:30:18 UTC
Created attachment 174286 [details]
Possible fix for the GSL build issues

This (hopefully) fixes the GSL build issues I've seen.
Comment 4 Florian Krohm 2024-10-01 20:46:59 UTC
I reran with your patch on my Ubuntu instance. No failures - neither in GSL tests nor in memcheck runs.
Comment 5 Andreas Arnez 2024-10-09 15:16:24 UTC
(In reply to Florian Krohm from comment #4)
> I reran with your patch on my Ubuntu instance. No failures - neither in GSL
> tests nor in memcheck runs.
Good. I pushed this patch as commit bbdd783268a56348f824e421ab1306077b2ae70a, just to ensure that `make auxchecks' can be executed again.
Comment 6 Paul Floyd 2024-10-14 05:53:22 UTC
I also see that buildbot s390 is passing 'make auxchecks'.