MDEV-40750 gcc-16.1.0 on ppc64 causes innodb to fail to compile - #5546
MDEV-40750 gcc-16.1.0 on ppc64 causes innodb to fail to compile#5546grooverdan wants to merge 1 commit into
Conversation
Assembler comes up with the error: unrecognized opcode: `dcbstps' dcbstps is a Power 10 instruction. The default target arch on most platforms is Power 8 or 9. Added the target power10 to the function pmem_phwsync. The execution of this function is gated on the ISA 3.1 in pmem_persist_init so there's no chance of a SIGILL.
| # elif defined __powerpc64__ | ||
| __attribute__((target("cpu=power10"))) | ||
| static void pmem_phwsync(const void* buf, size_t size) |
There was a problem hiding this comment.
According to https://godbolt.org this attribute is not supported on clang nor on GCC up to version 9. There is no GCC 10 or 11 available for this platform.
I think that it is more future-proof to hide the high-level instruction from the compiler, similar to what we did in #5105.
There is a clang available on https://godbolt.org. For clang, no matter what I try, I get no code emitted at all when I enable "Compile to binary object" in the output options. That option is more important on GCC, because GCC lacks a built-in assembler and is just copying the inline assembler input to output without validating it. I tested GCC with the following:
void f(void *u) {
__asm__ __volatile__(".long (0x7cc000AC | %0 << 11)" :: "r"(u) : "memory");
}There was a problem hiding this comment.
rhel9 is 11.5.0. rhel8 8.5.0 which is where the gcc9 come in.
Waiting on CI results a bit to be sure.
Not sure yet of the hiding the high level is the way to go. Its a bit of a different mapping to the 5105 PR.
on clang (sid) taking an extract of the function:
buildbot@5bb9477a0460:/build$ clang++ -c -o x.o /source/x.c++
'power10' is not a recognized processor for this target (ignoring processor)
'power10' is not a recognized processor for this target (ignoring processor)
'power10' is not a recognized processor for this target (ignoring processor)
'power10' is not a recognized processor for this target (ignoring processor)
'power10' is not a recognized processor for this target (ignoring processor)
buildbot@5bb9477a0460:/build$ objdump -d x.o
x.o: file format elf64-powerpcle
Disassembly of section .text:
0000000000000000 <_Z12pmem_phwsyncPKvm>:
0: f0 ff 61 f8 std r3,-16(r1)
4: e8 ff 81 f8 std r4,-24(r1)
8: f0 ff 61 e8 ld r3,-16(r1)
c: 7f ff 80 38 li r4,-129
10: 38 20 63 7c and r3,r3,r4
14: e0 ff 61 f8 std r3,-32(r1)
18: f0 ff 61 e8 ld r3,-16(r1)
1c: e8 ff 81 e8 ld r4,-24(r1)
20: 14 22 63 7c add r3,r3,r4
24: d8 ff 61 f8 std r3,-40(r1)
28: e0 ff 61 e8 ld r3,-32(r1)
2c: d8 ff 81 e8 ld r4,-40(r1)
30: 40 20 23 7c cmpld r3,r4
34: 1c 00 80 40 bge 50 <_Z12pmem_phwsyncPKvm+0x50>
38: e0 ff 61 e8 ld r3,-32(r1)
3c: ac 18 c0 7c dcbstps 0,r3
40: e0 ff 61 e8 ld r3,-32(r1)
44: 80 00 63 38 addi r3,r3,128
48: e0 ff 61 f8 std r3,-32(r1)
4c: dc ff ff 4b b 28 <_Z12pmem_phwsyncPKvm+0x28>
50: ac 04 80 7c phwsync
54: 20 00 80 4e blr
...
buildbot@5bb9477a0460:/build$ clang++ --version
Debian clang version 21.1.8 (10)
Target: powerpc64le-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/lib/llvm-21/bin
Weird warnings but the syncs are there.
| # endif | ||
| } | ||
|
|
||
| # if __GNUC__ >= 11 || (defined __clang_major__ && __clang_major__ >= 18) |
There was a problem hiding this comment.
Based on my experiment, it seems that both #if predicates had better be changed to one of the following:
# if (__GNUC__ >= 11 && __GNUC__ < 16) || (defined __clang_major__ && __clang_major__ >= 18)
We can revisit this if the build starts to fail on clang.
There was a problem hiding this comment.
clang 21 seems fine. I'll recheck again on the gcc define versions.
gkodinov
added
the
MariaDB Foundation
3 participants
Assembler comes up with the error:
unrecognized opcode: `dcbstps'
dcbstps is a Power 10 instruction. The default target arch on most platforms is Power 8 or 9.
Added the target power10 to the function pmem_phwsync. The execution of this function is gated on the ISA 3.1 in pmem_persist_init so there's no chance of a SIGILL.
Before and after on sid container on ppc64le: