Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
Hi Daniel! On 3/2/22 23:17, Daniel Black wrote: > The selective CFLAGS on specific files are there to enable > optimizations in certain functions. Elsewhere in the > code there is runtime detection made of the VSX/vpmsum to actually use the > code. So, it turns out that doesn't work, see [1]: /<>/extra/mariabackup/xbstream.cc /tmp/ccwobTGg.s: Assembler messages: /tmp/ccwobTGg.s:48: Error: unrecognized opcode: `tbegin.' /tmp/ccwobTGg.s:106: Error: unrecognized opcode: `tabort.' /tmp/ccwobTGg.s:151: Error: unrecognized opcode: `tend.' Can't you just change the code to check for the compiler baseline in use before emitting any POWER8 instructions? Upstream code really shouldn't use POWER8 instructions unconditionally. Debian's ppc64 big-endian port uses the POWER5 baseline, not POWER8. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007216 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
On 3/3/22 19:06, Tom Grzybowski wrote: >> If this still violates the policy, I'd like to know now so I can >> implement solutions that drop support for ppc64 POWER5+ >> and support hardware like ppc64le, POWER8+ that we actually do have >> hardware for and can support. > > If that happens, all of us with Power5 and Power4 CPS would be dropped from > Debian! Don't worry, this won't be necessary. mariadb does even build on the venerable Motorola 68000 CPU which is much older than POWER5 [1], so there is absolutely no reason to assume it wouldn't run on any variant on PowerPC. I think all that mariadb needs is a little input from porters for the various architectures to get the code more portable and more robust. I have to admit, working on the code base is a little frustrating due to the many parallel versions of MariaDB but I think it's feasible. Adrian > [1] https://buildd.debian.org/status/package.php?p=mariadb-10.6=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
On Thu, Mar 3, 2022 at 8:16 AM John Paul Adrian Glaubitz wrote: > > Hello! > > On 3/2/22 21:14, Otto Kekäläinen wrote: > > A recent build regression on ppc64el is preventing a new MariaDB version > > from migrating from unstable to testing. > > > > Could any experts on this list help out? > > I don't know where this code is coming from, but this is definitely wrong: > > > https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/mysys/CMakeLists.txt#L145 > > The code is forcing compiler flags based on the architecture and thus > overriding the > baseline. This is a baseline violation and not allowed per Debian Policy. > > And, in particular, it violates the baseline of the ppc64 port which is using > POWER5, > not POWER8. John, The selective CFLAGS on specific files are there to enable optimizations in certain functions. Elsewhere in the code there is runtime detection made of the VSX/vpmsum to actually use the code. So for POWER5 it should be there but dormant. Likewise for the bug here. We've got a htmxlintrin.h header insisting on the -mhtm, backed up the compiler that doesn't define the __builtin_tbegin builtins without the cflags. We use the htm target function attribute to compile specific functions that use it, however the use of instructions is still behind a runtime check. We can't include the header check inside a function, otherwise we are defining an inline function within a function. My work in progress fix is along these lines: https://github.com/MariaDB/server/commit/6df3911b61ba669285c08b1456276217c7881292 note just below the standard view of this commit at the bottom, there is transactional_lock_enabled that does runtime detection. But it's still failing (https://buildbot.mariadb.org/#/grid?branch=bb-10.6-danielblack-MDEV-27936-ppc64-htm-build-fail , for sid only, and only recent (https://buildbot.mariadb.org/#/grid?branch=10.6)), proving sid is true to its name. If this still violates the policy, I'd like to know now so I can implement solutions that drop support for ppc64 POWER5+ and support hardware like ppc64le, POWER8+ that we actually do have hardware for and can support.
Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
Hello! On 3/2/22 21:14, Otto Kekäläinen wrote: > A recent build regression on ppc64el is preventing a new MariaDB version from > migrating from unstable to testing. > > Could any experts on this list help out? I don't know where this code is coming from, but this is definitely wrong: > https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/mysys/CMakeLists.txt#L145 The code is forcing compiler flags based on the architecture and thus overriding the baseline. This is a baseline violation and not allowed per Debian Policy. And, in particular, it violates the baseline of the ppc64 port which is using POWER5, not POWER8. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1006527: [debian-mysql] Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
Control: forwarded -1 https://jira.mariadb.org/browse/MDEV-27936 This was actually already in progress upstream. Sorry for escalating to list before noticing this.
Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
Hello! A recent build regression on ppc64el is preventing a new MariaDB version from migrating from unstable to testing. Could any experts on this list help out? Please use reply-to-all, I don't subscribe to the list. Builds on both ppc64 and ppc64el fail due to misc errors related to htmxlintrin: htmxlintrin.h:25:3: error: #error "HTM instruction set not enabled" htmxlintrin.h:58:25: error: ‘__builtin_tbegin’ was not declared in this scope; did you mean ‘__builtin_tan’? htmxlintrin.h:71:28: error: ‘__builtin_get_texasr’ was not declared in this scope; did you mean ‘__builtin_gettext’? htmxlintrin.h:108:3: error: ‘__builtin_tresume’ was not declared in this scope; did you mean ‘__builtin_trunc’? htmxlintrin.h:158:7: error: ‘__builtin_ttest’ was not declared in this scope; did you mean ‘__builtin_strstr’? Details at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006527
Bug#1006527: mariadb-10.6: FTBFS on ppc64/ppc64el: htmxlintrin.h errors
Source: mariadb-10.6 Version: 1:10.6.7-1 Tags: upstream, confirmed, help, ftbfs User: debian-powe...@lists.debian.org Usertags: ppc64el, ppc64 Builds on both ppc64 and ppc64el fail due to misc errors related to htmxlintrin: htmxlintrin.h:25:3: error: #error "HTM instruction set not enabled" htmxlintrin.h:58:25: error: ‘__builtin_tbegin’ was not declared in this scope; did you mean ‘__builtin_tan’? htmxlintrin.h:71:28: error: ‘__builtin_get_texasr’ was not declared in this scope; did you mean ‘__builtin_gettext’? htmxlintrin.h:108:3: error: ‘__builtin_tresume’ was not declared in this scope; did you mean ‘__builtin_trunc’? htmxlintrin.h:158:7: error: ‘__builtin_ttest’ was not declared in this scope; did you mean ‘__builtin_strstr’? Example of error in full context: In file included from /<>/storage/innobase/include/transactional_lock_guard.h:73, from /<>/storage/innobase/include/buf0buf.h:43, from /<>/storage/innobase/include/dict0mem.h:45, from /<>/storage/innobase/include/dict0dict.h:32, from /<>/storage/innobase/include/btr0btr.h:31, from /<>/storage/innobase/btr/btr0btr.cc:28: /usr/lib/gcc/powerpc64-linux-gnu/11/include/htmxlintrin.h:165:27: error: ‘__builtin_get_texasr’ was not declared in this scope; did you mean ‘__builtin_gettext’? 165 | texasrl = (texasrl_t) __builtin_get_texasr (); | ^~~~ | __builtin_gettext This is a recent regression as builds of 10.6.5 still worked for ppc64el: https://buildd.debian.org/status/logs.php?pkg=mariadb-10.6=ppc64el However builds for ppc64 were broken for the lifespan of 10.6 in Debian: https://buildd.debian.org/status/logs.php?pkg=mariadb-10.6=ppc64 For MariaDB 10.5 builds of both ppc64el and ppc64 worked fine for at least a year: https://buildd.debian.org/status/logs.php?pkg=mariadb-10.5=ppc64 https://buildd.debian.org/status/logs.php?pkg=mariadb-10.5=ppc64el
