[Bug target/97444] New: [nvptx] stack atomics

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97444

            Bug ID: 97444
           Summary: [nvptx] stack atomics
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

There's currently a bunch of tests failing:
...
FAIL: gcc.dg/atomic/c11-atomic-exec-6.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-6.c   -O1  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-6.c   -O2  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-6.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-6.c   -O3 -g  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-6.c   -Os  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-7.c   -O0  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-7.c   -O1  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-7.c   -O2  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-7.c   -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-7.c   -O3 -g  execution test
FAIL: gcc.dg/atomic/c11-atomic-exec-7.c   -Os  execution test
FAIL: gcc.dg/atomic/stdatomic-op-5.c   -O0  execution test
FAIL: gcc.dg/atomic/stdatomic-op-5.c   -O1  execution test
FAIL: gcc.dg/atomic/stdatomic-op-5.c   -O2  execution test
FAIL: gcc.dg/atomic/stdatomic-op-5.c   -O3 -g  execution test
FAIL: gcc.dg/atomic/stdatomic-op-5.c   -Os  execution test
...
due to using atomics with stack memory.

The nvptx atomic ops do not support using stack memory.

I've been marking test-cases with atomic builtins using stack with
dg-require-effective-target sync_int_long_stack, which is ok because they're
just builtins.

But it's another thing when atomics are part of the language like in the
examples above.

In principle, it should possible to generate a run-time test using isspacep,
and switch between using an atomic op or a non-atomic fallback (that is either
an atom.add.u32, or an add.u32, because it's effectively atomic in .local
memory).

OTOH, we want a mode of operation where we generate atomics as currently,
without the runtime test to have smaller and faster code.

So, perhaps, a switch -mstack-atomics.