[Bug target/100678] [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations

2022-02-02 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678

Tom de Vries  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Tom de Vries  ---
Marking resolved-fixed.

[Bug target/100678] [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations

2022-02-02 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678

--- Comment #3 from Tom de Vries  ---
This testcase should be passing since commit
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e0451f93d9faa13495132f4e246e9bef30b51417
([nvptx] Add some support for .local atomics).

It's possible that we'll put this functionality behind some -mstack-atomics,
and that it'll be necessary for the test-case to add the option, but for now
that not the case.

[Bug target/100678] [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations

2021-05-19 Thread tschwinge at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678

--- Comment #2 from Thomas Schwinge  ---
I ran into this in a different OpenACC context (OpenACC privatization levels),
where in testcases we're trying to use 'atomic' on 'private' variables.  ...
which for nvptx offloading only works for gang-private (PTX '.shared'), but
fails for everything else, per PR83812 ("old" failure mode).

(In reply to Tom de Vries from comment #1)
> I'm not sure what you aim to achieve with the test-case.

To document the current failure mode -- a deficiency in the OpenACC/nvptx
implementation.  So that there is precedence for this, and it doesn't appear
just in the upcoming OpenACC privatization levels testcases.


And then, as reported in this issue here, I found the "wrong reduction result"
problem ("new" failure mode), which seems to be another deficiency in the
OpenACC/nvptx implementation.


> My inclination would be to skip it for nvptx, which AFAIU is opposite to
> your intent when adding it.  So, perhaps just remove it?

I'd rather conditionalize the nvptx offloading XFAIL appropriately for both the
"old" and "new" failure modes, and then eventually un-XFAIL, once these issues
have been addressed.

[Bug target/100678] [OpenACC/nvptx] 'libgomp.oacc-c-c++-common/private-atomic-1.c' FAILs (differently) in certain configurations

2021-05-19 Thread vries at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100678

--- Comment #1 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #0)
> At this point, it's (a) unclear whether the PR83812 restriction indeed is
> supposed to be lifted for certain modern GPU hardware/SM levels/CUDA Driver
> releases,

Looking at the latest ptx isa spec, 7.3, we have:
...
Atomic operations may be used only with .global and .shared spaces and with
generic addressing, where the address points to .global or .shared space.
...

That seems pretty clear.

It's also not unusual for different archs to have different failure modes.

I'm not sure what you aim to achieve with the test-case.

My inclination would be to skip it for nvptx, which AFAIU is opposite to your
intent when adding it.  So, perhaps just remove it?