Hi!
On 2021-04-09T13:00:39+0200, I wrote:
> On 2021-03-25T12:02:15+0100, I wrote:
>> On 2021-03-11T17:52:55+0100, I wrote:
>>> On 2021-02-23T22:52:38+0100, Jakub Jelinek via Gcc-patches
>>> wrote:
On Tue, Feb 23, 2021 at 09:43:51PM +, Kwok Cheung Yeung wrote:
> On 19/02/2021 7:12 pm
Hi!
On 2021-03-25T12:02:15+0100, I wrote:
> On 2021-03-11T17:52:55+0100, I wrote:
>> On 2021-02-23T22:52:38+0100, Jakub Jelinek via Gcc-patches
>> wrote:
>>> On Tue, Feb 23, 2021 at 09:43:51PM +, Kwok Cheung Yeung wrote:
On 19/02/2021 7:12 pm, Kwok Cheung Yeung wrote:
> I have incl
On Fri, Mar 26, 2021 at 04:19:56PM +0100, Tobias Burnus wrote:
> Hi Jakub,
>
> great suggestion – I did now as proposed.
>
> On 26.03.21 15:46, Jakub Jelinek via Gcc-patches wrote:
> > On Fri, Mar 26, 2021 at 03:42:22PM +0100, Tobias Burnus wrote:
> > > How about the following patch? It moves the
Hi Jakub,
great suggestion – I did now as proposed.
On 26.03.21 15:46, Jakub Jelinek via Gcc-patches wrote:
On Fri, Mar 26, 2021 at 03:42:22PM +0100, Tobias Burnus wrote:
How about the following patch? It moves the aux function to
libgomp.c-c++-common/on_device_arch.c
and #includes it in the
On Fri, Mar 26, 2021 at 03:42:22PM +0100, Tobias Burnus wrote:
> How about the following patch? It moves the aux function to
> libgomp.c-c++-common/on_device_arch.c
> and #includes it in the new wrapper files
> libgomp.{c,fortran}/on_device_arch.c.
> (Based on the observation that #include with r
Hi Thomas, hi all,
your commit causes compile fails:
cc1: fatal error: ../lib/on_device_arch.c: No such file or directory
FAIL: libgomp.c/../libgomp.c-c++-common/task-detach-6.c (test for excess errors)
FAIL: libgomp.c/pr99555-1.c (test for excess errors)
FAIL: libgomp.fortran/task-detach-6.f90
Hi!
On 2021-03-11T17:52:55+0100, I wrote:
> On 2021-02-23T22:52:38+0100, Jakub Jelinek via Gcc-patches
> wrote:
>> On Tue, Feb 23, 2021 at 09:43:51PM +, Kwok Cheung Yeung wrote:
>>> On 19/02/2021 7:12 pm, Kwok Cheung Yeung wrote:
>>> > I have included the current state of my patch. All task-
Hi!
On 2021-02-23T22:52:38+0100, Jakub Jelinek via Gcc-patches
wrote:
> On Tue, Feb 23, 2021 at 09:43:51PM +, Kwok Cheung Yeung wrote:
>> On 19/02/2021 7:12 pm, Kwok Cheung Yeung wrote:
>> > I have included the current state of my patch. All task-detach-* tests
>> > pass when executed withou
On Thu, Feb 25, 2021 at 04:21:31PM +, Kwok Cheung Yeung wrote:
> Reversing the order reduces the hole to 3 bytes:
>
> size_t num_dependees;/*80 8 */
> union {
> gomp_sem_t * completion_sem; /*88 8 */
>
comment.
Otherwise LGTM.
I will get this committed later if the regression tests finish with no
surprises.
Thank you for your time in reviewing this patch!
Kwok
From 462c86549de28f28d5a71e4a7e83e2c17fd19c17 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Thu, 21 Jan 2021 05:38:47 -0800
Su
On Wed, Feb 24, 2021 at 06:17:01PM +, Kwok Cheung Yeung wrote:
> > 1) while linux --enable-futex and accel gomp_sem_t is small (int), rtems
> > and especially posix gomp_sem_t is large; so while it might be a good
> > idea to inline gomp_sem_t on config/{linux,accel} into the union, for
team. If I omit the 'omp parallel' (to try to get
an undeferred task), GCC refuses to compile (only 'distribute', 'parallel' or
'loop' regions are allowed to be strictly nested inside 'teams' region). And you
can't nest 'omp teams'
On Tue, Feb 23, 2021 at 09:43:51PM +, Kwok Cheung Yeung wrote:
> On 19/02/2021 7:12 pm, Kwok Cheung Yeung wrote:
> > I have included the current state of my patch. All task-detach-* tests
> > pass when executed without offloading or with offloading to GCN, but
> > with offloading to Nvidia, tas
On 19/02/2021 7:12 pm, Kwok Cheung Yeung wrote:
I have included the current state of my patch. All task-detach-* tests pass when
executed without offloading or with offloading to GCN, but with offloading to
Nvidia, task-detach-6.* hangs consistently but everything else passes (probably
because
On Mon, Feb 22, 2021 at 02:49:44PM +0100, Jakub Jelinek wrote:
> So, I think for the team != gomp_thread ()->ts.team
> && !do_wake
> && gomp_team_barrier_waiting_for_tasks (&team->barrier)
> && team->task_detach_count == 0
> case, we need to wake up 1 thread anyway and arrange for it to do:
>
On Fri, Feb 19, 2021 at 07:12:42PM +, Kwok Cheung Yeung wrote:
> I have opted for a union of completion_sem (for tasks that are undeferred)
> and a struct gomp_team *detach_team (for deferred tasks) that holds the team
> if the completion event has not yet fulfilled, or NULL if is it. I don't s
ding to GCN, but with offloading to
Nvidia, task-detach-6.* hangs consistently but everything else passes (probably
because of the missing gomp_team_barrier_done?).
Kwok
From 31a5c736910036364fd1f0f3cf7ac28437864a27 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Thu, 21 Jan 2021 05:38:
On Fri, Jan 29, 2021 at 7:53 AM Jakub Jelinek via Gcc-patches
wrote:
>
> On Thu, Jan 21, 2021 at 07:33:34PM +, Kwok Cheung Yeung wrote:
> > The detach support clearly needs more work, but is this particular patch
> > okay for trunk?
>
> Sorry for the delay.
>
> I'm afraid it is far from being
On Thu, Jan 21, 2021 at 07:33:34PM +, Kwok Cheung Yeung wrote:
> The detach support clearly needs more work, but is this particular patch
> okay for trunk?
Sorry for the delay.
I'm afraid it is far from being ready.
> @@ -2402,17 +2437,41 @@ ialias (omp_in_final)
> void
> omp_fulfill_event
On 21/01/2021 7:33 pm, Kwok Cheung Yeung wrote:
With Nvidia and GCN offloading though, task-detach-6 hangs... I _think_ the
reason why it 'worked' before was because the taskwait allowed tasks with detach
clauses to always complete immediately after execution. Since that backdoor has
been close
patch okay
for trunk?
Thanks
Kwok
From 12cc24c937e9294d5616dd0cd9a754c02ffb26fa Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung
Date: Thu, 21 Jan 2021 05:38:47 -0800
Subject: [PATCH] openmp: Fix intermittent hanging of task-detach-6 libgomp
tests [PR98738]
This adds support for the task detach clause to taskwa
21 matches
Mail list logo
