spec/f32.wast test 1603 fails with GCC 13

[rathann]

When running binaryen 111 test suite after building it with GCC 13 on x86_64 running Fedora rawhide, I get the following failure:

1603/2511 CHECKING: ( assert_return ( invoke min ( f32.const 0x0p+0 ) ( f32.const -0x0p+0 ) ) ( f32.const -0x0p+0 ) ) [line: 1621]
seen 0, expected -0
Fatal: unexpected, should be identical

I have no idea why this is happening, especially since the previous test:

1602/2511 CHECKING: ( assert_return ( invoke min ( f32.const -0x0p+0 ) ( f32.const 0x0p+0 ) ) ( f32.const -0x0p+0 ) ) [line: 1620]
seen -0, expected -0

succeeds and differs only in argument order. Compiler bug perhaps?

NOTE: Successful compilation with GCC 13 requires a small patch adding explicit includes for <cstdint> to src/wat-lexer.h, which I'll open a PR for soon.

[kripken]

Might be worth trying santizers on that test (in both gcc and clang), perhaps there is undefined behavior that gcc uses. Or, building a debug build would also be useful to check to see if optimizations are involved.

[rathann]

@kripken I'd be happy to try sanitizers on that test. Could you give me some pointers on how to invoke them? The issue remains present in 112 release.

[kripken]

Sure, here is how CI builds with address sanitizer:

https://github.com/WebAssembly/binaryen/blob/7c3a4690028beaa187e5b1810200359b6336b088/.github/workflows/ci.yml#L134-L154

Basically add -fsanitize=address to compile and link commands, using some CMake flags there. Can also try address,undefined for undefined behavior as well.

[ptrcnull]

hitting the same issue with binaryen 112 or newer on Alpine edge, looks like a similar issue also happens with the corresponding max() call

2001/2510 CHECKING: ( assert_return ( invoke max ( f32.const -0x0p+0 ) ( f32.const 0x0p+0 ) ) ( f32.const 0x0p+0 ) ) [line: 2019]
seen -0, expected 0
Fatal: unexpected, should be identical

maybe it's an issue with std::signbit? i tried reproducing the issue in compiler explorer, but couldn't get it to fail in the same way

[ptrcnull]

and, well, the same happens with the corresponding f64 functions

[rathann]

FWIW this is no longer reproducible with binaryen 118 on current Fedora rawhide (GCC 14.1.1).

[kripken]

Thanks for confirming @rathann , let's close this then.

[rathann]

Fedora 39 (gcc 13.3.1) and 40 (gcc 14.1.1) builds passed as well.

[ptrcnull]

Binaryen 118 on Alpine with GCC 13.2.1 works as well

[kripken]

Great!