This seems to have been introduced with CL505455 addition of __atomic_load_n.

This bit exceeds the max lock-free size (0 bytes) looks weird, a size can never be zero, It is probably some sort of clang or arm target bug since you can reproduce it with a C program.

clang-14 --target=armv5-none-linux-gnu -mfloat-abi=hard --sysroot=/usr/arm-linux-gnueabihf test.c
test.c:8:15: warning: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes) [-Watomic-alignment]
        int result = __atomic_load_n(&myVar, __ATOMIC_RELAXED);
                     ^

You could try the compiler flag -Wno-atomic-alignment, it should get rid of the error.

I think "max size 0" means that the platform does not natively support atomic operations and they have to be emulated. https://bugs.llvm.org/show_bug.cgi?id=38593

Interesting! That seems to be the real reason, the error message is just poorly worded.

Mauri

I wonder if we can just ignore the warning in runtime/cgo. Since we build with -Werror it ends up failing the build. Depending on the C compiler version -Wno-atomic-alignment might not even be available. The user can also supply this flag manually when it is needed, but given the misleading error message that might not be initially clear, but that is clang to blame.

diff --git a/src/runtime/cgo/cgo.go b/src/runtime/cgo/cgo.go
index 1e3a502918..4bd8e6a53a 100644
--- a/src/runtime/cgo/cgo.go
+++ b/src/runtime/cgo/cgo.go
@@ -29,6 +29,8 @@ package cgo
 
 #cgo solaris CPPFLAGS: -D_POSIX_PTHREAD_SEMANTICS
 
+#cgo arm CFLAGS: -Wno-atomic-alignment
+
 */
 import "C"

cc @golang/runtime @golang/arm

In triage, one thing we're wondering is if this error is actually benign and we're OK with unaligned atomics (which IIRC break some atomicity guarantees) or if we need to actually fix this in the code CL 505455 modified.

CC @cuonglm @ianlancetaylor

I don't think the issue here is alignment. I think clang is just warning that ARMv5 doesn't really have atomics, as @corhere mentioned.

In our own atomic code, we call into a kernel-provided stub to help with atomics on ARM <7: https://cs.opensource.google/go/go/+/master:src/runtime/internal/atomic/sys_linux_arm.s;l=79-83.

In the kernel, that is https://elixir.bootlin.com/linux/latest/source/arch/arm/kernel/entry-armv.S#L749 -> https://elixir.bootlin.com/linux/latest/source/arch/arm/include/asm/assembler.h#L374. For ARMv5 that is ultimately a nop, because Linux simply doesn't support SMP for ARMv5 at all.

I don't know what the clang-generated code looks like (if someone could provide the disassembly, that would be helpful), but I suspect it is just warning that it has to call into a helper.

If this is accurate, I suspect ignoring the warning is fine.

Compiler Explorer

a:
  push {r11, lr}
  ldr r0, .LCPI0_0
  mov r1, #0
  bl __atomic_load_4
  pop {r11, lr}
  bx lr

The __atomic_load_4 symbol is defined in GCC's libatomic. (When the -latomic flag is provided, Compiler Explorer will link the binary but won't render the disassembly for some reason.) The libatomic function is presumably implemented in terms of the kernel memory-barrier helper.

If we only see the warnings for runtime/cgo/gcc_libinit.c, then we can add a #pragma line to that file to disable the warning. Something like

#pragma GCC diagnostic ignored "-Watomic-alignment"

I just confirmed that this works. It is less intrusive than disabling the warning in a #cgo directive. Thanks, Ian.

Change https://go.dev/cl/562348 mentions this issue: runtime/cgo: ignore -Watomic-alignment in gcc_libinit.c

Change https://go.dev/cl/567556 mentions this issue: runtime/cgo: ignore unknown warning options