sleef: Certain tests fail on gcc 12.0.0 pre-release

Fedora Linux just introduced a pre-release build of gcc 12.0.0 to the development version of Fedora (Rawhide). (Fedora 36 will be released with GCC 12 in mid-2022.) This has resulted in a few new test failures in the sleef package on several architectures.

The release notes for GCC 12 are here. It’s not obvious whether these new failures are a Sleef bug or a GCC bug. Disabling LTO makes no difference.

armv7hl

OK (no failures)

i686

OK (no failures)

x86_64

The following tests FAILED:
	 28 - iutpurecfma_scalar (Failed)
	 29 - iutypurecfma_scalar (Failed)

aarch64

The following tests FAILED:
	 14 - iutpurec_scalar (Failed)
	 15 - iutypurec_scalar (Failed)
	 17 - iutpurecfma_scalar (Failed)
	 18 - iutypurecfma_scalar (Failed)

ppc64le

The following tests FAILED:
	  8 - iutpurec_scalar (Failed)
	  9 - iutypurec_scalar (Failed)
	 11 - iutpurecfma_scalar (Failed)
	 12 - iutypurecfma_scalar (Failed)

s390x

The following tests FAILED:
	  3 - iutyzvector2 (Failed)
	  6 - iutyzvector2nofma (Failed)
	  8 - iutpurec_scalar (Failed)
	  9 - iutypurec_scalar (Failed)
	 11 - iutpurecfma_scalar (Failed)
	 12 - iutypurecfma_scalar (Failed)

About this issue

Original URL
State: open
Created 2 years ago
Comments: 17 (10 by maintainers)

Commits related to this issue

math/sleef: Update to latest upstream commit (2021-04-05) This updates sleef to latest upstream commit 85440a5e87dae36ca1b891de14bc83b441ae7c43 which fixes a bunch of things including AVX2 detection.... — committed to freebsd/freebsd-ports by deleted user a year ago

Most upvoted comments

Indeed it is a workaround, but we were worried about the implications on performance (although scalar performance should not matter).

For now, I’d rather favor strict correctness over maximum scalar performance. In any case, once the GCC fix is released, I’ll drop -ftrapping-math and go back to respecting whatever Sleef chooses upstream.

musicinmybrain on Mar 18, 2024

Indeed it is a workaround, but we were worried about the implications on performance (although scalar performance should not matter). We might drop the -fno-trapping-math in the future as we believe it was introduced for the wrong reasons (only -fno-math-errno was necessary to make sure no call to libm was generate for fsqrt).

blapie on Mar 18, 2024