* Jakub Jelinek:
> Not all targets support GNU style function versioning where one can have
> multiple symbol versions for the same symbol name, and I wanted to
> avoid GOMP_task2, GOMP_task3 etc.
Why? If it is about aesthetics, wouldn't compliance with language
standards and ABI requirements be
On Thu, Jan 21, 2021 at 08:32:52AM +0100, Thomas Schwinge wrote:
> > and which of those depend, priority and detach argument is present depends
> > on the bits in flags.
> > I'm afraid the compiler just decided to spill the detach = NULL store in
> > if ((flags & GOMP_TASK_FLAG_DETACH) == 0)
> >
Hi!
On 2021-01-20T17:40:58+0100, Jakub Jelinek via Gcc-patches
wrote:
> On Wed, Jan 20, 2021 at 05:04:39PM +0100, Florian Weimer wrote:
>> Sorry, this appears to cause OpenMP task state corruption in RPM. We
>> have only seen this on s390x.
>
> Haven't actually verified it, but my suspection is
On Wed, Jan 20, 2021 at 05:04:39PM +0100, Florian Weimer wrote:
> Sorry, this appears to cause OpenMP task state corruption in RPM. We
> have only seen this on s390x.
Haven't actually verified it, but my suspection is that this is a caller
stack corruption.
We play with fire with the GOMP_task A
* Kwok Cheung Yeung:
> From 788687f87ad41e51258738ce068ee38d7b24defc Mon Sep 17 00:00:00 2001
> From: Kwok Cheung Yeung
> Date: Fri, 15 Jan 2021 04:49:36 -0800
> Subject: [PATCH] openmp: Add support for the OpenMP 5.0 task detach clause
Sorry, this appears to cause OpenMP task state corruption i
Hi Jakub,
> On Sun, Jan 17, 2021 at 04:25:24PM +0100, Andreas Schwab wrote:
>> On Jan 17 2021, Jakub Jelinek via Gcc-patches wrote:
>>
>> > Kwok, I guess you can reproduce it even on Linux with --disable-linux-futex
>>
>> And all targets that are not explicitly configured in
>> libcomp/configure
On Mon, Jan 18, 2021 at 07:10:07AM +0100, Sebastian Huber wrote:
> Hello Jakub,
>
> On 17/01/2021 17:04, Jakub Jelinek via Gcc-patches wrote:
>
> > On Sun, Jan 17, 2021 at 04:25:24PM +0100, Andreas Schwab wrote:
> > > On Jan 17 2021, Jakub Jelinek via Gcc-patches wrote:
> > >
> > > > Kwok, I gue
Hello Jakub,
On 17/01/2021 17:04, Jakub Jelinek via Gcc-patches wrote:
On Sun, Jan 17, 2021 at 04:25:24PM +0100, Andreas Schwab wrote:
On Jan 17 2021, Jakub Jelinek via Gcc-patches wrote:
Kwok, I guess you can reproduce it even on Linux with --disable-linux-futex
And all targets that are no
On Sun, Jan 17, 2021 at 04:25:24PM +0100, Andreas Schwab wrote:
> On Jan 17 2021, Jakub Jelinek via Gcc-patches wrote:
>
> > Kwok, I guess you can reproduce it even on Linux with --disable-linux-futex
>
> And all targets that are not explicitly configured in
> libcomp/configure.tgt, where --enabl
On Jan 17 2021, Jakub Jelinek via Gcc-patches wrote:
> Kwok, I guess you can reproduce it even on Linux with --disable-linux-futex
And all targets that are not explicitly configured in
libcomp/configure.tgt, where --enable-linux-futex is a no-op.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.o
Hi Jakub,
> On Sun, Jan 17, 2021 at 12:26:26PM +0100, Rainer Orth wrote:
>> >> I have applied your other suggestions, and have retested the gomp.exp and
>> >> libgomp tests. The full testrun started yesterday showed no regressions.
>> >> If
>> >> you have no further issues then I will commit this
On Sun, Jan 17, 2021 at 12:26:26PM +0100, Rainer Orth wrote:
> >> I have applied your other suggestions, and have retested the gomp.exp and
> >> libgomp tests. The full testrun started yesterday showed no regressions. If
> >> you have no further issues then I will commit this later tonight ahead of
Hi Jakub,
>> I have applied your other suggestions, and have retested the gomp.exp and
>> libgomp tests. The full testrun started yesterday showed no regressions. If
>> you have no further issues then I will commit this later tonight ahead of
>> stage4.
>
> LGTM, thanks.
this patch broke Solaris
On Sat, Jan 16, 2021 at 07:19:51PM +, Kwok Cheung Yeung wrote:
> > I think you don't need this loop, instead you could just check
> > if (bitmap_bit_p (&generic_head, DECL_UID (detach_decl))
> > || bitmap_bit_p (&firstprivate_head, DECL_UID (detach_decl))
> >
Thanks for the review.
On 16/01/2021 9:25 am, Jakub Jelinek wrote:
On Fri, Jan 15, 2021 at 03:07:56PM +, Kwok Cheung Yeung wrote:
+ {
+ tree detach_decl = OMP_CLAUSE_DECL (*detach_seen);
+
+ for (pc = &clauses, c = clauses; c ; c = *pc)
+ {
+ bool
On Fri, Jan 15, 2021 at 03:07:56PM +, Kwok Cheung Yeung wrote:
> + {
> + tree detach_decl = OMP_CLAUSE_DECL (*detach_seen);
> +
> + for (pc = &clauses, c = clauses; c ; c = *pc)
> + {
> + bool remove = false;
> + if ((OMP_CLAUSE_CODE (c) == OMP_CLAUSE
On Fri, Jan 15, 2021 at 04:58:25PM +, Kwok Cheung Yeung wrote:
> On 15/01/2021 3:07 pm, Kwok Cheung Yeung wrote:
> > I have tested bootstrapping on x86_64 (no offloading) with no issues,
> > and running the libgomp testsuite with Nvidia offloading shows no
> > regressions. I have also tested al
On 15/01/2021 3:07 pm, Kwok Cheung Yeung wrote:
I have tested bootstrapping on x86_64 (no offloading) with no issues, and
running the libgomp testsuite with Nvidia offloading shows no regressions. I
have also tested all the gomp.exp tests in the main gcc testsuite, also with no
issues. I am cur
On 10/12/2020 2:38 pm, Jakub Jelinek wrote:
On Wed, Dec 09, 2020 at 05:37:24PM +, Kwok Cheung Yeung wrote:
--- a/gcc/c/c-typeck.c
+++ b/gcc/c/c-typeck.c
@@ -14942,6 +14942,11 @@ c_finish_omp_clauses (tree clauses, enum
c_omp_region_type ort)
pc = &OMP_CLAUSE_CHAIN (c);
c
Hello
Thanks for the review. Due to the Christmas holidays I have not finished
addressing all these issues yet, but I expect to be done by the end of this
week. Can this patch still make it for GCC 10, as I believe stage 4 is starting
soon?
Thanks
Kwok
On 10/12/2020 2:38 pm, Jakub Jelinek
On Thu, Dec 10, 2020 at 03:38:40PM +0100, Jakub Jelinek via Gcc-patches wrote:
One further thing, the detach clause effectively writes to the var, so
unless you mark the clause decl addressable as I've suggested, you should
if (omp_shared_to_firstprivate_optimizable_decl_p (decl))
omp_mark_stores
On Thu, Dec 10, 2020 at 03:38:40PM +0100, Jakub Jelinek via Gcc-patches wrote:
> I don't understand this. My reading of:
> "The event-handle will be considered as if it was specified on a
> firstprivate clause. The use of a variable in a detach clause expression of a
> task
> construct causes an
On Wed, Dec 09, 2020 at 05:37:24PM +, Kwok Cheung Yeung wrote:
> --- a/gcc/c/c-typeck.c
> +++ b/gcc/c/c-typeck.c
> @@ -14942,6 +14942,11 @@ c_finish_omp_clauses (tree clauses, enum
> c_omp_region_type ort)
> pc = &OMP_CLAUSE_CHAIN (c);
> continue;
>
> + case OMP_CLAUSE_DE
On 09/12/2020 5:53 pm, Jakub Jelinek wrote:
On Wed, Dec 09, 2020 at 05:37:24PM +, Kwok Cheung Yeung wrote:
I believe this patch is largely complete now. I have done a bootstrap on
x86_64 and run the testsuites with no regressions. I have also run the
libgomp testsuite with offloading to Nvid
On Wed, Dec 09, 2020 at 05:37:24PM +, Kwok Cheung Yeung wrote:
> I believe this patch is largely complete now. I have done a bootstrap on
> x86_64 and run the testsuites with no regressions. I have also run the
> libgomp testsuite with offloading to Nvidia and AMD GCN devices, also with
> no re
Hello
This is a further update of the patch for task detach support.
- The memory for the event is not mapped on the target. This means that if
omp_fulfill_event is called from an 'omp target' section with a target that
does not share memory with the host, the event will not be fulfilled (and
Hello
This is an updated version of the WIP patch for task detach support. Any
comments would be welcome!
On 11/11/2020 7:06 pm, Kwok Cheung Yeung wrote:
- No error checking at the front-end.
The detach clause is now parsed properly in C, C++ and Fortran, and will raise
an error if the syn
Hello
This is a WIP implementation of the OpenMP 5.0 task detach clause. The task
construct can now take a detach clause, passing in a variable of type
omp_event_handle_t. When the construct is encountered, space for an event is
allocated and the event variable is set to point to the new event
28 matches
Mail list logo
