https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98321
--- Comment #4 from Thomas Schwinge <tschwinge at gcc dot gnu.org> --- (In reply to Tom de Vries from comment #3) > (In reply to Thomas Schwinge from comment #2) > > 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'. > > Ah, I was not aware of usage of openacc beyond the offloading setup. ;-D > For my understanding, is this just a way for you to easily reproduce some > problem really occurring elsewhere, or is this actually used for something? No, I don't think this has any practical use other than testing. I had been looking into how/when PTX 'atom' is used for reductions, and first had a look what the back end currently might emit at all, found SDIM 'atomic_fetch_add<mode>', and SF 'atomic_fetch_addsf'. I tried to get these used via '(void) __atomic_fetch_add (&a, b, __ATOMIC_RELAXED);', which works fine for integer types, but 'error: operand type ‘float *’ is incompatible with argument 1 of ‘__atomic_fetch_add’' (didn't research the rationale behind that), so resorted to 'acc atomic'. Further analysis to be done. (Can floating-point type atomic generally not be supported, given that '__atomic_fetch_add' rejects it? Is OMP atomic handling doing something wrong for these even for nvptx target (real, not via offloading)? Is something wrong in the nvptx back end?) This isn't important right now; I just filed the issue as I'd found it.
