Created attachment 1477282 [details] reduced standalone test case Description of problem: After an introduction of __build_clz() based pow2_ceil() implementation [1] in jemalloc, a unit test [2] started to fail in the test-suite on s390x. It was reported as [3], but it turned into a compiler issue (IMO) caused by the -funroll-loops option. [1] https://github.com/jemalloc/jemalloc/commit/4c548a61c89b0472b9952fcc4090eb00c2a88870 [2] https://github.com/jemalloc/jemalloc/blob/dev/test/unit/bit_util.c [3] https://github.com/jemalloc/jemalloc/issues/1307 Version-Release number of selected component (if applicable): gcc-8.2.1-2.fc29.s390x
Seems it's affecting only s390x, this came from our CI for jemalloc that checks also armv7, aarch64, ppc64, ppc64le and x86_64.
The error message from running the test case is Failed assertion: (pow2_ceil_u32(((uint32_t)1) << i)) == (((uint32_t)1) << i) --> 1 != 2: Unexpected result, i=1
Have you tried -fsanitize=undefined?
I've tried now and nothing is reported [sharkcz@devel10 ~]$ gcc -std=gnu11 -Wall -pipe -g3 -O2 -funroll-loops -fsanitize=undefined -o t t.c [sharkcz@devel10 ~]$ ./t Failed assertion: (pow2_ceil_u32(((uint32_t)1) << i)) == (((uint32_t)1) << i) --> 1 != 2: Unexpected result, i=1
for the record, the generic pow2_ceil() produces correct results in the test
------- Comment From Andreas.Krebbel.com 2018-11-20 11:23 EDT------- This is a bug in the clztidi2 pattern in the S/390 backend of GCC. I've just committed a patch to mainline. https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01736.html Although it appears to be quite difficult to trigger this probably should be backported to basically all distro levels currently in use :(
Hanns, I guess it makes sense to clone this bug for RHEL gcc too.
(In reply to Dan Horák from comment #7) > Hanns, I guess it makes sense to clone this bug for RHEL gcc too. . Hello Dan, ... agree ... ... please go ahead cloning this bugzilla to the related RHEL releases ... Thanks for your attention and support.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.