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:

binaryen/.github/workflows/ci.yml

Lines 134 to 154 in 7c3a469

	build-asan:
	name: asan
	runs-on: ubuntu-latest
	env:
	ASAN_OPTIONS: "symbolize=1"
	COMPILER_FLAGS: "-fsanitize=address"
	steps:
	- uses: actions/setup-python@v1
	with:
	python-version: '3.x'
	- uses: actions/checkout@v1
	with:
	submodules: true
	- name: install ninja
	run: sudo apt-get install ninja-build
	- name: install Python dev dependencies
	run: pip3 install -r requirements-dev.txt
	- name: cmake
	run: |
	mkdir -p out
	cmake -S . -B out -G Ninja -DCMAKE_INSTALL_PREFIX=out/install -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_FLAGS="$COMPILER_FLAGS" -DCMAKE_CXX_FLAGS="$COMPILER_FLAGS"

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!