Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL)
Description
Clang expects 8-byte alignment for some 64-bit atomic operations
in some 32-bit targets. Native instruction lock cmpxchg8b (for x86)
should only require 4-byte alignment.
As a result laterst mariadb fails to build with clang on 32bit/x86 architecture because it
can not find the missing symbol
undefined reference to `__atomic_fetch_or_8'
here is a shortened testcase that can reproduce the problem with clang
#include <stdint.h>
|
# ifdef __GNUC__
|
typedef __attribute__((__aligned__(8))) uint64_t ATOMIC_U64; |
# else
|
typedef uint64_t ATOMIC_U64; |
# endif
|
|
|
int main() {return 0;} |
|
|
#ifdef BUGGY
|
uint64_t foo(uint64_t *val, uint64_t op)
|
#else
|
uint64_t foo(ATOMIC_U64 *val, uint64_t op)
|
#endif
|
{
|
return __atomic_or_fetch(val, op, __ATOMIC_ACQ_REL); |
}
|
|
|
|
compiles ok with `gcc -m32` or `clang -m32` fine but interesting thing happens with
`gcc -DBUGGY -m32` or `clang -DBUGGY -m32`
and you see the difference. Clang says
/tmp/a.c:17:12: warning: misaligned atomic operation may incur significant performance penalty; the expected alignment (8 bytes) exceeds the actual alignment (4 bytes) [-Watomic-alignment]
|
return __atomic_or_fetch(val, op, __ATOMIC_ACQ_REL);
|
^
|
1 warning generated.
|
/usr/bin/ld: /tmp/a-4a5d79.o: in function `foo':
|
a.c:(.text+0x6b): undefined reference to `__atomic_fetch_or_8'
|
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)
|
|
|
|
but gcc sails along.
so I guess we need to make sure that any data being accessed atomically is aligned to 64bit as well to
help the compiler a bit here.
Attachments
Issue Links
- relates to
-
MDEV-34464 Specify memory order for PFS atomics
-
- Open
-
-
-
- Open
-