ray and simd tests fail on i686

[amigadave]

While updating the Fedora packaging for the 1.10.8 release, I came across a test failure on i686:

+ /usr/bin/meson test -C redhat-linux-build --num-processes 6 --print-errorlogs
ninja: Entering directory `/builddir/build/BUILD/graphene-1.10.8/redhat-linux-build'
ninja: no work to do.
 1/22 mutest / general            OK              0.03s
 2/22 mutest / hooks              OK              0.02s
 3/22 mutest / types              OK              0.02s
 4/22 graphene / box              OK              0.02s   65 subtests passed
 5/22 graphene / euler            OK              0.02s   10 subtests passed
 6/22 graphene / frustum          OK              0.01s   21 subtests passed
 7/22 graphene / matrix           OK              0.03s   70 subtests passed
 8/22 graphene / plane            OK              0.02s   13 subtests passed
 9/22 graphene / point            OK              0.02s   24 subtests passed
10/22 graphene / point3d          OK              0.02s   36 subtests passed
11/22 graphene / quad             OK              0.02s   12 subtests passed
12/22 graphene / quaternion       OK              0.01s   24 subtests passed
▶ 13/22 - intersection kind should be NONE FAIL          
▶ 14/22 - reciprocal() to return positive infinity in the X component FAIL          
▶ 14/22 - reciprocal() to return negative infinity in the Y component FAIL          
13/22 graphene / ray              ERROR           0.03s   exit status 1
>>> MALLOC_PERTURB_=116 MUTEST_OUTPUT=tap /builddir/build/BUILD/graphene-1.10.8/redhat-linux-build/tests/ray
――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
stderr:
(test program exited with status code 1)
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
15/22 graphene / rect             OK              0.03s   69 subtests passed
14/22 graphene / simd             ERROR           0.03s   exit status 1
>>> MALLOC_PERTURB_=122 MUTEST_OUTPUT=tap /builddir/build/BUILD/graphene-1.10.8/redhat-linux-build/tests/simd
――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
stderr:
(test program exited with status code 1)
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
16/22 graphene / size             OK              0.02s   17 subtests passed
17/22 graphene / sphere           OK              0.02s   17 subtests passed
18/22 graphene / triangle         OK              0.02s   56 subtests passed
19/22 graphene / vec2             OK              0.02s   37 subtests passed
20/22 graphene / vec3             OK              0.02s   51 subtests passed
21/22 graphene / vec4             OK              0.01s   63 subtests passed
22/22 graphene / introspection.py OK              0.08s   1 subtests passed
Summary of Failures:
13/22 graphene / ray              ERROR           0.03s   exit status 1
14/22 graphene / simd             ERROR           0.03s   exit status 1
Ok:                 20  
Expected Fail:      0   
Fail:               2   
Unexpected Pass:    0   
Skipped:            0   
Timeout:            0

The full build log is https://kojipkgs.fedoraproject.org//work/tasks/7875/84387875/build.log but I do not have an i686 machine around to test, sadly. I think that I can get access to a test system to try to get some artifacts out of a build, if that would be useful.

[ebassi]

I don't have a 32bit machine either, unfortunately, so support for 32bit architectures is similar to the support for ARM NEON: a best effort.

I also assume that this was with the scalar implementation?

[mcrha]

This is still true. This is the meson summary, if it helps:

Build targets in project: 46
NOTICE: Future-deprecated features used:
 * 0.56.0: {'dependency.get_pkgconfig_variable'}
graphene 1.10.8
  Directories
    prefix         : /usr
    libdir         : lib
    includedir     : include
  SIMD
    SSE            : NO
    GCC vector     : NO
    ARM NEON       : NO
  Features
    GObject types  : YES
    Introspection  : YES
  Build
    Documentation  : YES
    Tests          : YES
    Installed tests: YES
  Subprojects
    mutest         : YES
  User defined options
    auto_features  : enabled
    bindir         : /usr/bin
    buildtype      : plain
    datadir        : /usr/share
    gtk_doc        : true
    includedir     : /usr/include
    infodir        : /usr/share/info
    libdir         : /usr/lib
    libexecdir     : /usr/libexec
    localedir      : /usr/share/locale
    localstatedir  : /var
    mandir         : /usr/share/man
    prefix         : /usr
    sbindir        : /usr/bin
    sharedstatedir : /var/lib
    sysconfdir     : /etc
    wrap_mode      : nodownload

[ebassi]

I don't have a 32bit machine

This is also still true.

[mcrha]

Right, right, I meant in case it would be something with a compiler or anything, but no, the latest built in a rawhide (aka bleeding edge things) is failing in the tests the same way. Pity the tests are not more chatty what failed and why.

[mcrha]

For what it's worth, the tests pass fine with gcc-8.3.1 (and similarly old libraries; I did not get to any newer but still lower than 3 years old), but they fail with gcc-15.1.1. I tried a local mock build using fedpkg in an updated graphene.spec file from fedpkg clone --anonymous graphene like this:

fedpkg mockbuild --root fedora-42-i386 --no-cleanup-after
fedpkg mockbuild --root fedora-42-i386 --shell

then in the mock shell:

cd build/BUILD/graphene-1.10.8-build/graphene-1.10.8/
MALLOC_PERTURB_=122 MUTEST_OUTPUT=tap MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 LD_LIBRARY_PATH=/builddir/build/BUILD/graphene-1.10.8-build/graphene-1.10.8/redhat-linux-build/src UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MESON_TEST_ITERATION=1 /builddir/build/BUILD/graphene-1.10.8-build/graphene-1.10.8/redhat-linux-build/tests/ray

and the failed test is:

# can intersect on axis
# ray_intersects_box (../tests/ray.c:192): 1  ≡  false
not ok 18 - intersection kind should be NONE

and for the other test:

MUTEST_OUTPUT=tap MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 MALLOC_PERTURB_=114 LD_LIBRARY_PATH=/builddir/build/BUILD/graphene-1.10.8-build/graphene-1.10.8/redhat-linux-build/src UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MESON_TEST_ITERATION=1 /builddir/build/BUILD/graphene-1.10.8-build/graphene-1.10.8/redhat-linux-build/tests/simd
....
# simd_operators_reciprocal (../tests/simd.c:313): NaN  ≈  +∞
not ok 34 - reciprocal() to return positive infinity in the X component
# simd_operators_reciprocal (../tests/simd.c:317): NaN  ≈  -∞
not ok 35 - reciprocal() to return negative infinity in the Y component

I do not know how to debug this, thus if you could guide me a bit, I'll be happy to help.

[mcrha]

It looks like the graphene_isnan() is failing on i686?

Breakpoint 1, ray_intersects_box () at ../tests/ray.c:192
192       mutest_expect ("intersection kind should be NONE",

Unable to load the Python 'rpm' module.  Lack of this module disables
the RPM suggestions mechanism which recommends shell commands for
installing missing debuginfo packages.  To enable this functionality,
please install the python3-rpm package.
(gdb) l
187
188       graphene_point3d_init (&origin, 0, 0, 0);
189       graphene_vec3_init (&direction, 0, 0.495176f, -0.868793f);
190       graphene_ray_init (&ray, &origin, &direction);
191
192       mutest_expect ("intersection kind should be NONE",
193                      mutest_int_value (graphene_ray_intersects_box (&ray, &box)),
194                      mutest_to_be_false,
195                      NULL);
196
(gdb) s
graphene_ray_intersects_box (r=0xffffd110, b=0xffffd130) at ../src/graphene-ray.c:590
590       return graphene_ray_intersect_box (r, b, NULL) != GRAPHENE_RAY_INTERSECTION_KIND_NONE;
(gdb) s
0xf7fa577f in graphene_ray_intersect_box (r=0xffffd110, b=0xffffd130, t_out=0x0) at ../src/graphene-ray.c:489
489       graphene_vec3_subtract (&(b->min), &r->origin, &inv_min);
(gdb) p *r
$1 = {origin = {value = {x = 0, y = 0, z = 0, w = 0}}, direction = {value = {x = 0, y = 0.495175838, z = -0.868792772, w = 0}}}
(gdb) p *b
$2 = {min = {value = {x = 41.843132, y = 27.3569031, z = -50.3683357, w = 0}}, max = {value = {x = 51.6980782, y = 29.0801716, z = -50.3683357, w = 0}}}
(gdb) n
490       graphene_vec3_multiply (&inv_min, &inv_dir, &inv_min);
(gdb) p *r
$3 = {origin = {value = {x = 0, y = 0, z = 0, w = 0}}, direction = {value = {x = 0, y = 0.495175838, z = -0.868792772, w = 0}}}
(gdb) p *b
$4 = {min = {value = {x = 41.843132, y = 27.3569031, z = -50.3683357, w = 0}}, max = {value = {x = 51.6980782, y = 29.0801716, z = -50.3683357, w = 0}}}
(gdb) p inv_min
$5 = {value = {x = 41.843132, y = 27.3569031, z = -50.3683357, w = 0}}
(gdb) p inv_dir
$6 = {value = {x = -nan(0x400000), y = 2.01948452, z = -1.15102243, w = -nan(0x400000)}}
(gdb) n
493       graphene_vec3_subtract (&(b->max), &r->origin, &inv_max);
(gdb) p inv_min
$7 = {value = {x = -nan(0x400000), y = 55.2468414, z = 57.9750862, w = -nan(0x400000)}}
(gdb) p inv_dir
$8 = {value = {x = -nan(0x400000), y = 2.01948452, z = -1.15102243, w = -nan(0x400000)}}
(gdb) n
494       graphene_vec3_multiply (&inv_max, &inv_dir, &inv_max);
(gdb) p inv_max
$9 = {value = {x = 51.6980782, y = 29.0801716, z = -50.3683357, w = 0}}
(gdb) p *r
$10 = {origin = {value = {x = 0, y = 0, z = 0, w = 0}}, direction = {value = {x = 0, y = 0.495175838, z = -0.868792772, w = 0}}}
(gdb) p *b
$11 = {min = {value = {x = 41.843132, y = 27.3569031, z = -50.3683357, w = 0}}, max = {value = {x = 51.6980782, y = 29.0801716, z = -50.3683357, w = 0}}}
(gdb) n
497       if (graphene_vec3_get_x (&inv_dir) >= 0.f)
(gdb) p inv_dir
$12 = {value = {x = -nan(0x400000), y = 2.01948452, z = -1.15102243, w = -nan(0x400000)}}
(gdb) p inv_max
$13 = {value = {x = -nan(0x400000), y = 58.7269554, z = 57.9750862, w = -nan(0x400000)}}
(gdb) s
0xf7fa922c in graphene_vec3_get_x (v=0xffffd020) at ../src/graphene-vectors.c:747
747       return graphene_simd4f_get_x (v->value);
(gdb) s
graphene_simd4f_get_x (s=...) at ../src/graphene-simd4f.c:1123
1123      return s.x;
(gdb) p s.x
$14 = -nan(0x400000)
(gdb) n
graphene_ray_intersect_box (r=0xffffd110, b=0xffffd130, t_out=0x0) at ../src/graphene-ray.c:504
504           tx_min = graphene_vec3_get_x (&inv_max);
(gdb) 
505           tx_max = graphene_vec3_get_x (&inv_min);
(gdb) 
509       if (graphene_vec3_get_y (&inv_dir) >= 0.f)
(gdb) p tx_min
$15 = -nan(0x400000)
(gdb) p tx_max
$16 = -nan(0x400000)
(gdb) n
511           ty_min = graphene_vec3_get_y (&inv_min);
(gdb) 
512           ty_max = graphene_vec3_get_y (&inv_max);
(gdb) 
520       if (t_out != NULL)
(gdb) p ty_min
$17 = 55.2468414
(gdb) p ty_max
$18 = 58.7269554
(gdb) n
523       if ((tx_min > ty_max) || (ty_min > tx_max))
(gdb) 
529       if (ty_min > tx_min || graphene_isnan (tx_min))
(gdb) p tx_min
$19 = -nan(0x400000)
(gdb) s
531       if (ty_max < tx_max || graphene_isnan (tx_max))
(gdb) 
535       if (graphene_vec3_get_z (&inv_dir) >= 0.f)
(gdb) n
542           tz_min = graphene_vec3_get_z (&inv_max);
(gdb) 
543           tz_max = graphene_vec3_get_z (&inv_min);
(gdb) 
546       if ((tx_min > tz_max) || (tz_min > tx_max))
(gdb) p tz_min
$20 = 57.9750862
(gdb) p tz_max
$21 = 0
(gdb) p inv_max
$22 = {value = {x = -nan(0x400000), y = 58.7269554, z = 57.9750862, w = -nan(0x400000)}}
(gdb) p inv_min
$23 = {value = {x = -nan(0x400000), y = 55.2468414, z = 57.9750862, w = -nan(0x400000)}}
(gdb) n
549       if (tz_min > tx_min || graphene_isnan (tx_min))
(gdb) s
551       if (tz_max < tx_max || graphene_isnan (tx_max))
(gdb) 
555       if (tx_max < 0)
(gdb) n
558       if (tx_min >= 0)
(gdb) 
560           if (t_out)
(gdb) 
      Assertion failure: 1  ≡  false at ray_intersects_box (../tests/ray.c:192)
      ✗ intersection kind should be NONE
ray_intersects_box () at ../tests/ray.c:199

[mcrha]

It looks like the graphene_isnan() is failing on i686?

Nope, it's not it. I tried a bit more and when I saw there are some "optimized out" variables, I let the code compile with -O0 to get to them. Guess what, the tests pass fine with it. The same with -O1. As soon as -O2 is used the two tests fail, but not with a lower optimization level. It looks like a compiler problem then, right? I'll ask the gcc folks in Fedora.

[mcrha]

I'll ask the gcc folks in Fedora.

It's here: https://bugzilla.redhat.com/show_bug.cgi?id=2374913

[mcrha]

Please see the explanation in the https://bugzilla.redhat.com/show_bug.cgi?id=2374913#c3

The -ffast-math you have in the meson.build causes the problem.

[gcomes]

I had the same problem on openSUSE. The test ray and simd failing when using gcc version 12 to 15.1 for i586. And I figured out that the gcc option -ffast-math was causing the error. Once I removed such option from the test the error was gone.
Since the test without -ffast-math takes less than a second to be executed on a modern computer, I really don't see the need for the -ffast-math option.
Also after reading:
https://simonbyrne.github.io/notes/fastmath/
I have the feeling that it doesn't make much sense to use -ffast-math in order to run tests to check if the code is giving correct result.

[swagtoy]

Judging from the stacktraces I got, the issue isn't particularly -ffast-math alone, but it's only -ffinite-math-only which happens to be toggled by -ffast-math. As noted by the GCC manpage

       -ffinite-math-only
           Allow optimizations for floating-point arithmetic that assume that arguments and results are
           not NaNs or +-Infs.

It's obvious here why the graphene_isnan call is failing, because that is specifically an edge case that is ignored entirely. (stupid, but whatever). Hell, it doesn't just break on i686 here, but it's failing here too on an amd64 device!

Can reproduce a scenario by doing CFLAGS="-ffast-math -fno-finite-math-only" meson setup build and running tests, everything passes here, but with -ffast-math alone, things will break.

I don't think there is a possible fix here for that. -ffast-math isn't a default for a reason. As such, passing -fno-finite-math-only is a good workaround, and is probably the only thing that can be done in this scenario (and should be done regardless, IMO)