public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libgomp/113627] New: Detached tasks released without call to omp_fulfill_event
@ 2024-01-27  4:20 schuchart at icl dot utk.edu
  2024-01-27  4:31 ` [Bug libgomp/113627] " pinskia at gcc dot gnu.org
  0 siblings, 1 reply; 2+ messages in thread
From: schuchart at icl dot utk.edu @ 2024-01-27  4:20 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 113627
           Summary: Detached tasks released without call to
                    omp_fulfill_event
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: schuchart at icl dot utk.edu
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 57236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57236&action=edit
Pre-processed reproducer

We saw a problem in a benchmark OpenMP application that executes a loop in
which two tasks are created per iteration. Each pair of tasks in an iteration
is chained through a dependency on an array element and the first task is being
detached. We found that the second (dependent) task is executed after the
dependee is executed even though the even has not been fulfilled.

I'm attaching the preprocessed sources of a reproducer (that's as small as I
could get, apologies if it's still too complex). If the execution is correct
the program will hang because none of the events are fulfilled. If the
execution is incorrect an assert will trigger because the second task is
executed and the array value is not set properly (it is set by an outside
entity in our benchmark before the event is released). It is important to note
that the issue occurs only with more than 64 iterations when running on a
single thread. Starting from 65 iterations the dependent task is executed
without the event being fulfilled. If OMP_NUM_THREADS is set to 2 the crossover
is 128/129 iterations.

To build the example:

$ gcc -g -O0 -fopenmp example_detach.c -o example

To run the example (will hang due to the event not being fulfilled):

$ OMP_NUM_THREADS=1 ./example -t 64

To run the example and trigger the assert because the dependent task is
executed prematurely:

$ OMP_NUM_THREADS=1 ./example -t 64


I'm running on an AMD Epyc Rome machine on a GNU/Linux system. I see this
behavior with a system-wide gcc 12.2.0 installed through spack and a gcc 13.2.0
I built myself using this configure:

$ ../configure --prefix=$INSTALLDIR --enable-languages=c --disable-multilib
--with-pic --disable-bootstrap

Please let me know if I can provide anything else.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug libgomp/113627] Detached tasks released without call to omp_fulfill_event
  2024-01-27  4:20 [Bug libgomp/113627] New: Detached tasks released without call to omp_fulfill_event schuchart at icl dot utk.edu
@ 2024-01-27  4:31 ` pinskia at gcc dot gnu.org
  0 siblings, 0 replies; 2+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-01-27  4:31 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
My gut feeling is there is some variable is not being treated as atomic. 

That is there is a race condition somewhere. I am not saying you example code
has a race condition in it but rather that seems like the cause of the bug.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-01-27  4:31 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-27  4:20 [Bug libgomp/113627] New: Detached tasks released without call to omp_fulfill_event schuchart at icl dot utk.edu
2024-01-27  4:31 ` [Bug libgomp/113627] " pinskia at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).