ivmai / bdwgc

The Boehm-Demers-Weiser conservative C/C++ Garbage Collector (bdwgc, also known as bdw-gc, boehm-gc, libgc)

Home Page:https://www.hboehm.info/gc/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Zig warning of "large atomic operation may incur significant performance penalty" on 32-bit arm

ivmai opened this issue · comments

Source: master ()
Build: https://github.com/ivmai/bdwgc/actions/runs/7492494323/job/20396121916
Zig version: 0.12.0-dev.2076+8fd15c6ca
Host: Linux/x86_64
How to reproduce: zig build -Dtarget=armeb-linux-gnueabi -DBUILD_SHARED_LIBS=false -Denable_werror
Targets:

  • arm-linux-gnueabi
  • arm-linux-musleabi
  • armeb-linux-gnueabi
  • thumb-linux-gnueabi
  • thumb-linux-musleabi
  • thumb-linux-musleabihf

Output:

/home/runner/work/bdwgc/bdwgc/fnlz_mlc.c:11[9](https://github.com/ivmai/bdwgc/actions/runs/7492494323/job/20396132567#step:4:10):9: error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes)
/home/runner/work/bdwgc/bdwgc/include/private/gc_atomic_ops.h:96:25: note: expanded from macro 'AO_store'
/home/runner/work/bdwgc/bdwgc/alloc.c:402:9: error: large atomic operation may incur significant performance penalty; the access size (1 bytes) exceeds the max lock-free size (0  bytes)
/home/runner/work/bdwgc/bdwgc/include/private/gc_locks.h:271:27: note: expanded from macro 'ENTER_GC'
/home/runner/work/bdwgc/bdwgc/include/private/gc_atomic_ops.h:[10](https://github.com/ivmai/bdwgc/actions/runs/7492494323/job/20396132567#step:4:11)5:30: note: expanded from macro 'AO_char_store'
/home/runner/work/bdwgc/bdwgc/alloc.c:404:9: error: large atomic operation may incur significant performance penalty; the access size (1 bytes) exceeds the max lock-free size (0  bytes)
/home/runner/work/bdwgc/bdwgc/include/private/gc_locks.h:272:26: note: expanded from macro 'EXIT_GC'
/home/runner/work/bdwgc/bdwgc/include/private/gc_atomic_ops.h:105:30: note: expanded from macro 'AO_char_store'
/home/runner/work/bdwgc/bdwgc/dbg_mlc.c:762:[11](https://github.com/ivmai/bdwgc/actions/runs/7492494323/job/20396132567#step:4:12): error: large atomic operation may incur significant performance penalty; the access size (4 bytes) exceeds the max lock-free size (0  bytes)
/home/runner/work/bdwgc/bdwgc/include/private/gc_priv.h:2476:31: note: expanded from macro 'GC_SET_HAVE_ERRORS'
/home/runner/work/bdwgc/bdwgc/include/private/gc_atomic_ops.h:96:25: note: expanded from macro 'AO_store'
...

Current workaround is to exclude such configurations from the cross-compilation on GH Actions.
Another approach could be to use libatomic_ops.

I think it should be addressed on the zig side (with some low priority as there are not tier-1 targets).

zig bundles clang as the C compiler, so these errors are from clang / llvm. zig does specify loads of flags to clang, so all the default flags clang has are different when it is used from zig. Have the GC been built on these targets before with clang without these errors?

I really don't know much about the details of this so don't have a straight answer. Googling I found RIOT-OS/RIOT#12048 which has a similar error message.

rmutex.c:128:12: error: large atomic operation may incur significant performance penalty [-Werror,-Watomic-alignment]

zig sets lots of warning / error flags to avoid various errors, could it be that it is stricter than the defaults of other compilers? Is it correct, like do we actually want to align some atomic op here? Or maybe we need to turn of the warning?

FYI, there are some tracking issues for real projects using zig

It could perhaps be of interest to put together such a page for issues we find that are hampering the use of zig for bdwgc. It could help garner attention from the zig community...

Okay, there could be a workaround on bdwgc side (by using libatomic_ops instead of -D GC_BUILTIN_ATOMIC) but let's just leave this issue open.

Related to #602

Also, related commit 2ccb138