[Bug libgomp/88707] Random failures of libgomp.c++/task-reduction-(8|10|11|13).C

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Prathamesh Kulkarni
<prathamesh3492@gcc.gnu.org>:

https://gcc.gnu.org/g:8a47ae5c193bfc5d84f90a41b122f83b9cd6d691

commit r16-6912-g8a47ae5c193bfc5d84f90a41b122f83b9cd6d691
Author: Matthew Malcolmson <mmalcolmson@nvidia.com>
Date:   Tue Jan 20 03:29:04 2026 +0000

    libgomp: Enforce tasks executed lexically after scheduled

    In PR122314 we noticed that our implementation of a barrier could
    execute tasks from the next "Task scheduling" region.  This was because
    of a race condition where a barrier could be "completed", and some
    thread raced ahead to schedule another task on the "next" barrier all
    before some other thread checks for a bit on the generation number to
    tell if there is a task pending.

    The solution provided here is to check whether the generation number has
    "incremented" past the state that this barrier was entered with.  As it
    happens the `state` variable already provided to
    `gomp_barrier_handle_tasks` is enough for the targets to tell whether
    the current global generation has incremented from the existing one.

    This requires some changes in the two loops in bar.c that are waiting on
    tasks being available.  These loops now need to check for "generation
    has incremented" rather than "generation is identical to one increment
    forward".  Without such an adjustment of the check a thread that is
    refusing to execute tasks because they have been scheduled for the next
    barrier will not continue into the next region until some other thread
    has completed the task (and removed the BAR_TASK_PENDING flag).

    This problem could be seen by a hang in testcases like
    task-reduction-13.c.

    Testing done:
    - Bootstrap & regtest on aarch64 and x86_64.
      - With & without _LIBGOMP_CHECKING_.
      - Testsuite with & without OMP_WAIT_POLICY=passive
    - Cross compilation & regtest on arm.
    - TSAN done on this as part of all my upstream patches.

    libgomp/ChangeLog:
            PR libgomp/122314
            PR libgomp/88707
            * config/gcn/bar.c (gomp_team_barrier_wait_end): Use
            gomp_barrier_state_is_incremented.
            (gomp_team_barrier_wait_cancel_end): Likewise.
            * config/gcn/bar.h (gomp_barrier_state_is_incremented,
            gomp_barrier_has_completed): New.
            * config/linux/bar.c (gomp_team_barrier_wait_end): Use
            gomp_barrier_state_is_incremented.
            (gomp_team_barrier_wait_cancel_end): Likewise.
            * config/linux/bar.h (gomp_barrier_state_is_incremented,
            gomp_barrier_has_completed): New.
            * config/nvptx/bar.h (gomp_barrier_state_is_incremented,
            gomp_barrier_has_completed): New.
            * config/posix/bar.c (gomp_team_barrier_wait_end): Use
            gomp_barrier_state_is_incremented.
            (gomp_team_barrier_wait_cancel_end): Likewise
            * config/posix/bar.h (gomp_barrier_state_is_incremented,
            gomp_barrier_has_completed): New.
            * config/rtems/bar.h (gomp_barrier_state_is_incremented,
            gomp_barrier_has_completed): New.
            * task.c (gomp_barrier_handle_tasks): Use
            gomp_barrier_has_completed.
            * testsuite/libgomp.c/pr122314.c: New test.

    Signed-off-by: Matthew Malcomson <mmalcomson@nvidia.com>