https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98321
--- Comment #2 from Thomas Schwinge <tschwinge at gcc dot gnu.org> --- Thanks for having a look. (In reply to Tom de Vries from comment #1) > Ok, let's first make a runnable test-case: > ... > $ cat src/libgomp/testsuite/libgomp.oacc-c/test.c > [...] > Indeed we see the cas, but that has nothing to do with support in the nvptx > port: > ... > atom.cas.b32 %r29, [%r25], %r22, %r28; > > ... > > This appears already at ompexp on the host, where we expand: > [...] > This is part of a generic problem with offloading, where choices are made in > the host compiler which are suboptimal or even unsupported in the offload > compiler. Yes, I'm aware of that problem -- and we should do something about it. > Ideally this should be addressed in the host compiler. (Strike the "ideally"?) > It may be possible to address this in the nvptx port by trying to detect the > unoptimal pattern and converting it to the optimal atom.add.f32. But > ultimately that's a workaround, and it's better to fix this at the source. I agree; don't see much point in investing effort in such a workaround (which doesn't sound easy either). However, my report was specifically for the nvptx target compiler. Just compile with 'nvptx-gcc -fopenacc -S' the code I posed, and compare '-DTYPE=int'/'-DTYPE=long' vs. '-DTYPE=float'.
