[MDEV-28162] clang compiler emits atomic library calls on x86/32bit - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Minor
Resolution: Fixed
Affects Version/s: 10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL), 10.8(EOL), 10.9(EOL)
Fix Version/s: 10.5.26, 10.6.19, 10.11.9, 11.1.6, 11.2.5, 11.4.3, 11.5.2, 11.6.1
Component/s: Performance Schema
Labels:

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

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

clang-64bit-atomics.patch
6 kB
2022-03-24 05:49

Issue Links

relates to

MDEV-34464 Specify memory order for PFS atomics

Open

MDEV-34465 Fix check-then-act races in PFS

Open

Activity

Ascending order - Click to sort in descending order

KHEM RAJ created issue - 2022-03-23 23:11

KHEM RAJ made changes - 2022-03-23 23:12

Field	Original Value	New Value
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 maridb 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 ```c #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.	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 maridb 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.

KHEM RAJ made changes - 2022-03-23 23:13

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 maridb 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.

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 maridb 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.

KHEM RAJ made changes - 2022-03-23 23:13

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 maridb 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.

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 maridb 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>
{{monospaced text}}
# 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.

KHEM RAJ made changes - 2022-03-23 23:14

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 maridb 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>
{{monospaced text}}
# 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.

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 maridb 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>
{{monospaced text
monot
}}
# 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.

KHEM RAJ made changes - 2022-03-23 23:14

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 maridb 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>
{{monospaced text
monot
}}
# 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.

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 maridb 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.

KHEM RAJ made changes - 2022-03-23 23:15

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 maridb 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.

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 maridb 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

{code:c}
#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);
}

{code}
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

{noformat}
/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)

{noformat}

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.

KHEM RAJ made changes - 2022-03-23 23:16

Attachment

clang-64bit-atomics.patch [ 62711 ]

KHEM RAJ made changes - 2022-03-24 05:49

Attachment

clang-64bit-atomics.patch [ 62711 ]

KHEM RAJ made changes - 2022-03-24 05:49

Attachment

clang-64bit-atomics.patch [ 62712 ]

Marko Mäkelä made changes - 2022-03-24 07:58

Component/s		Performance Schema [ 15627 ]
Fix Version/s		10.4 [ 22408 ]
Fix Version/s		10.5 [ 23123 ]
Fix Version/s		10.6 [ 24028 ]
Fix Version/s		10.7 [ 24805 ]
Fix Version/s		10.8 [ 26121 ]
Fix Version/s		10.9 [ 26905 ]
Affects Version/s		10.2 [ 14601 ]
Affects Version/s		10.3 [ 22126 ]
Affects Version/s		10.4 [ 22408 ]
Affects Version/s		10.5 [ 23123 ]
Affects Version/s		10.6 [ 24028 ]
Affects Version/s		10.7 [ 24805 ]
Affects Version/s		10.8 [ 26121 ]
Affects Version/s		10.9 [ 26905 ]
Labels		alignment beginner-friendly c++

Sergei Golubchik made changes - 2022-03-29 19:12

Assignee

Daniel Black [ danblack ]

Sergei Golubchik made changes - 2022-03-29 19:12

Fix Version/s	10.8 [ 26121 ]
Fix Version/s	10.9 [ 26905 ]

Sergei Golubchik made changes - 2022-03-29 19:13

Assignee

Daniel Black [ danblack ]

Nikita Malyavin [ nikitamalyavin ]

Julien Fritsch made changes - 2023-03-03 17:28

Fix Version/s

10.7 [ 24805 ]

Nikita Malyavin made changes - 2024-06-26 18:16

Link

This issue relates to MDEV-34464 [ MDEV-34464 ]

Nikita Malyavin made changes - 2024-06-26 18:32

Link

This issue relates to MDEV-34465 [ MDEV-34465 ]

Marko Mäkelä made changes - 2024-06-27 07:15

Fix Version/s		10.5.26 [ 29832 ]
Fix Version/s		10.6.19 [ 29833 ]
Fix Version/s		10.11.9 [ 29834 ]
Fix Version/s		11.1.6 [ 29835 ]
Fix Version/s		11.2.5 [ 29836 ]
Fix Version/s		11.4.3 [ 29837 ]
Fix Version/s		11.5.2 [ 29838 ]
Fix Version/s		11.6.1 [ 29847 ]
Fix Version/s	10.4 [ 22408 ]
Fix Version/s	10.5 [ 23123 ]
Fix Version/s	10.6 [ 24028 ]
Resolution		Fixed [ 1 ]
Status	Open [ 1 ]	Closed [ 6 ]

Nikita Malyavin made changes - 2024-06-27 14:11

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 maridb 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

{code:c}
#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);
}

{code}
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

{noformat}
/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)

{noformat}

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.

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

{code:c}
#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);
}

{code}
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

{noformat}
/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)

{noformat}

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.

People

Assignee:: Nikita Malyavin

Reporter:: KHEM RAJ

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2022-03-23 23:11

Updated:: 2024-06-27 15:00

Resolved:: 2024-06-27 07:15

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration