Control: severity -1 important Greetings everyone, focusing on the baseline violation aspect… Helmut Grohne, on 2021-06-02: > The check does not want to know whether the compiler supports > popcnt (which could be determined using AC_LINK_IFELSE), but whether the > CPU does and AC_LINK_IFELSE does not suffice here. > > Unfortunately such opportunistic use of the popcnt instruction violates > the i386 baseline as it does not include SSE4 at this time. This is a > serious bug. For Debian, such detection is not appropriate. Debian > builds must pass --disable-popcnt for any-i386. If the package is deemed > unusable without such performance optimizations, it should at least > depend on the appropriate isa-support package likely sse4.2-support. I have looked up the issue, and rebuilt the package on a popcnt enabled CPU. When disassembling the binary packages, I have seen no traces of *cnt instructions, neither in the libraries, nor in executable programs. I do see the following in the build log, which is quite concerning: CC=gcc CFLAGS=-g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security MORECFLAGS= -mpopcnt -march=native ~~~~~~~~ ~~~~~~~~~~~~~ The -march=native would cause even worse baseline violations than -mpopcnt, especially if the build occurs on very recent hardware. To eliminate both of these entries off the equation, one would have to configure the build with both --disable-popcnt and --enable-generic. Fortunately, note that the MORECFLAGS variable does not make it down to build options, although it is concatenated into CFLAGS in makefile.in. This seems to explain why I don't see baseline violations in the resulting binary objects on my end. Still, standard Debian options are accounted for properly. I believe our dh build process never uses upstream's makefile.in template, but an entirely autoreconf-ed one instead, which does not know anything of MORECFLAGS, hence the proper result in spite of the confusing options. Since the compilation does seem to result in baseline clean binaries, I dropped the severity to "important". I prefer not closing the bug, since I guess plans to adjust the logic for cross buildability could, eventually, end up injecting such option properly in the build process. Of course, please feel free to readjust the severity, if I missed an important thing in the problem at play. Hope this helps, -- Étienne Mollier <email@example.com> Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/8, please excuse my verbosity.
Description: PGP signature