for OpenMP - but nothing above hints at
> this is just usable there, asking for trouble.
The idea was that we restrict what VAR_DECLs we allow such a points-to-readonly
set,
but yeah this could use more documentation later.
I have for the time being pushed the attached patch to devel/omp/gcc-
On 2024/6/6 9:41 PM, Chung-Lin Tang wrote:
> This is v2 of the C/C++/middle-end parts of array/struct
> support for OpenACC reductions.
>
> The main changes are much fixed support for sub-arrays,
> and some new testcases.
>
> Tested on mainline using x86_64 host and nv
after approved for mainline.
Thanks,
Chung-Lin
2024-06-06 Chung-Lin Tang
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_clause_reduction): Adjustments for
OpenACC-specific cases.
* c-typeck.cc (c_oacc_reduction_defined_type_p): New function
kay, I've committed the attached patch, with the "early return upon
k->refcount == REFCOUNT_ACC_MAP_DATA" in gomp_increment/decrement_refcount.
If we continue to use k->refcount itself as the flag holder of map type, I
guess we will not be able to directly determine whe
Hi Thomas,
On 2024/3/15 7:24 PM, Thomas Schwinge wrote:
> Hi Chung-Lin!
>
> I realized: please add "PR libgomp/92840" to the Git commit log, as your
> changes are directly a continuation of my earlier changes.
Okay, I'll remember to do that.
...
> - if (n->refcount != REFCOUNT_INFINITY
r' in the "fn spec" attribute)
Other changes since first version of patch include:
1) update of C/C++ FE changes to new style in c-family/c-omp.cc
2) merging of two if cases in fortran/trans-openmp.cc like Thomas suggested
3) Update of readonly-2.c testcase to scan before/aft
Hi Thomas, Tobias,
On 2023/10/26 6:43 PM, Thomas Schwinge wrote:
> +++ b/gcc/tree.h
> @@ -1813,6 +1813,14 @@ class auto_suppress_location_wrappers
> #define OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE(NODE) \
> (OMP_CLAUSE_SUBCODE_CHECK (NODE,
> OMP_CLAUSE_MAP)->base.addressabl
gt; that I just pushed. I think you just need to handle
> 'REFCOUNT_ACC_MAP_DATA' like 'REFCOUNT_INFINITY' in
> 'libgomp/oacc-mem.c:goacc_enter_data_internal', 'if (n && struct_p)'?
> Please verify.
Fixed by adding another '&&
nt state
is okay to submit.
Tested without regressions on mainline (on top of first struct/array reduction
patch[1])
Thanks,
Chung-Lin
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-January/641669.html
2024-02-08 Chung-Lin Tang
gcc/fortran/ChangeLog:
* openmp.cc (oacc_reduction_
Updated my email address.
Thanks,
Chung-Lin
From ffeab69e1ffc0405da3a9222c7b9f7a000252702 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Thu, 25 Jan 2024 18:20:43 +
Subject: [PATCH] MAINTAINERS: Update my work email address
* MAINTAINERS: Update my work email address
IL instead of comment out. Will do this in next
iteration.
Thanks,
Chung-Lin
2024-01-02 Chung-Lin Tang
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_clause_reduction): Adjustments for
OpenACC-specific cases.
* c-typeck.cc (c_oacc_reduction_defined_type_p):
gt; we should just directly use 'TREE_READONLY' instead? We're only using
>> them in contexts where it's clear that the 'OMP_CLAUSE_SUBCODE_CHECK' is
>> satisfied, for example.
> I find directly using TREE_READONLY confusing.
FWIW, I've changed to
precisely to the exact innermost
default clause that was active at that program point.
Note, I got rid of the dummy OMP_CLAUSE_DEFAULT creation in this version,
since it seemed not really needed.
Re-tested on master on powerpc64le-linux/nvptx. Okay to commit?
Thanks,
Chung-Lin
2023-08-01 Chun
On 2023/7/11 2:33 AM, Chung-Lin Tang via Gcc-patches wrote:
> As we discussed earlier, the work for actually linking this to middle-end
> points-to analysis is a somewhat non-trivial issue. This first patch allows
> the language feature to be used in OpenACC directives first (with no effe
Hi Thomas,
On 2023/6/23 6:47 PM, Thomas Schwinge wrote:
>> +
>>ctx->clauses = *orig_list_p;
>>gimplify_omp_ctxp = ctx;
>> }
> Instead of this, in 'gimplify_omp_workshare', before the
> 'gimplify_scan_omp_clauses' call, do something like:
>
> if ((ort & ORT_ACC)
> && !omp_find
On 2023/6/16 5:13 PM, Thomas Schwinge wrote:
> OK with one small change, please -- unless there's a reason for doing it
> this way:
>
>> --- a/gcc/fortran/trans-openmp.cc
>> +++ b/gcc/fortran/trans-openmp.cc
>> @@ -4677,6 +4677,12 @@ gfc_trans_oacc_construct (gfc_code *code)
>> break;
>>
be used in OpenACC directives first (with no effect for
now).
The middle-end changes are probably going to be a later patch.
(Also CCing Tobias because of the Fortran bits)
Tested on powerpc64le-linux with nvptx offloading. Is this okay for trunk?
Thanks,
Chung-Lin
2023-07-10 Chung-Lin Tan
thout regressions using powerpc64le-linux/nvptx, okay for trunk?
Thanks,
Chung-Lin
2023-06-22 Chung-Lin Tang
libgomp/ChangeLog:
* libgomp.h (REFCOUNT_ACC_MAP_DATA): Define as (REFCOUNT_SPECIAL | 2).
* oacc-mem.c (acc_map_data): Adjust to use REFCOUNT_ACC_MAP_DATA,
initi
f what host-fallback
is doing,
though everything else should be completed by this patch.
Tested on powerpc64le-linux/nvptx, x64_64-linux/amdgcn tests pending.
Is this okay for trunk?
Thanks,
Chung-Lin
2023-06-13 Chung-Lin Tang
gcc/c/ChangeLog:
* c-parser.cc (c_parser_oacc_compu
Adjust testcase.
* gfortran.dg/goacc/default-5.f: Adjust testcase.
From 101305aee9b27c6df00d7c403e469bdf8d7f45a4 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Tue, 6 Jun 2023 03:46:29 -0700
Subject: [PATCH 2/2] OpenACC 2.7: default clause support for data constructs
This patch impl
t testcase.
* gfortran.dg/goacc/host_data-error.f90: New testcase.
* gfortran.dg/goacc/pr71704.f90: Adjust testcase.
From 0d17b8d24fa6079d6c289305e9644c3fecd429f1 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Tue, 6 Jun 2023 03:19:33 -0700
Subject: [PATCH 1/2] OpenACC 2.7: host_data must have
Hi Thomas,
On 2023/1/12 9:51 PM, Thomas Schwinge wrote:
> In my case, 'cuda_callback_wrapper' (expectedly) gets invoked with
> 'res != CUDA_SUCCESS' ("an illegal memory access was encountered").
> When we invoke 'GOMP_PLUGIN_fatal', this attempts to shut down the device
> (..., which deadlocks); t
Ping x6
On 2022/12/6 12:21 AM, Chung-Lin Tang wrote:
> Ping x5
>
> On 2022/11/22 12:24 上午, Chung-Lin Tang wrote:
>> Ping x4
>>
>> On 2022/11/8 12:34 AM, Chung-Lin Tang wrote:
>>> Ping x3.
>>>
>>> On 2022/10/31 10:18 PM, Chung-Lin Tang wrote:
Ping x5
On 2022/11/22 12:24 上午, Chung-Lin Tang wrote:
> Ping x4
>
> On 2022/11/8 12:34 AM, Chung-Lin Tang wrote:
>> Ping x3.
>>
>> On 2022/10/31 10:18 PM, Chung-Lin Tang wrote:
>>> Ping x2.
>>>
>>> On 2022/10/17 10:29 PM, Chung-Lin Tang wrote
Ping x4
On 2022/11/8 12:34 AM, Chung-Lin Tang wrote:
> Ping x3.
>
> On 2022/10/31 10:18 PM, Chung-Lin Tang wrote:
>> Ping x2.
>>
>> On 2022/10/17 10:29 PM, Chung-Lin Tang wrote:
>>> Ping.
>>>
>>> On 2022/9/21 3:45 PM, Chung-Lin Tang
Ping x3.
On 2022/10/31 10:18 PM, Chung-Lin Tang wrote:
> Ping x2.
>
> On 2022/10/17 10:29 PM, Chung-Lin Tang wrote:
>> Ping.
>>
>> On 2022/9/21 3:45 PM, Chung-Lin Tang via Gcc-patches wrote:
>>> Hi Tom,
>>> I had a patch submitted earl
Ping x2.
On 2022/10/17 10:29 PM, Chung-Lin Tang wrote:
> Ping.
>
> On 2022/9/21 3:45 PM, Chung-Lin Tang via Gcc-patches wrote:
>> Hi Tom,
>> I had a patch submitted earlier, where I reported that the current way of
>> implementing
>> barriers in libgomp on
Ping.
On 2022/9/21 3:45 PM, Chung-Lin Tang via Gcc-patches wrote:
> Hi Tom,
> I had a patch submitted earlier, where I reported that the current way of
> implementing
> barriers in libgomp on nvptx created a quite significant performance drop on
> some SPEChpc2021
> b
On 2022/9/21 5:01 PM, Jakub Jelinek wrote:
On Wed, Sep 21, 2022 at 03:45:36PM +0800, Chung-Lin Tang via Gcc-patches wrote:
Hi Tom,
I had a patch submitted earlier, where I reported that the current way of
implementing
barriers in libgomp on nvptx created a quite significant performance drop
her)
Thanks,
Chung-Lin
2022-09-21 Chung-Lin Tang
gcc/ChangeLog:
* config/nvptx/nvptx.cc (nvptx_print_operand): Add 'p'
case, adjust comments.
(enum nvptx_builtins): Add NVPTX_BUILTIN_BAR_RED_AND,
NVPTX_BUILTIN_BAR_RED_OR, and NVPTX_BUILTIN_BAR_RED_POPC.
backporting to GCC12 branch, if performance regression can be
considered a defect)
Thanks,
Chung-Lin
libgomp/ChangeLog:
2022-09-21 Chung-Lin Tang
* config/nvptx/bar.c (generation_to_barrier): Remove.
(futex_wait,futex_wake,do_spin,do_wait): Remove.
(GOMP
On 2022/8/26 4:15 PM, Chung-Lin Tang wrote:
> On 2022/8/4 9:31 PM, Koning, Paul wrote:
>>
>>
>>> On Aug 4, 2022, at 9:17 AM, Chung-Lin Tang wrote:
>>>
>>> On 2022/6/28 10:06 PM, Jakub Jelinek wrote:
>>>> On Thu, Jun 23, 2022 at 11:47:59P
Hi Joseph,
Jan-Benedict reported a build-bot error for the nios2 port under
--enable-werror-always:
options-save.cc: In function 'bool cl_target_option_eq(const cl_target_option*,
const cl_target_option*)':
options-save.cc:9291:38: error: comparison between two arrays
[-Werror=array-compare]
9
0697bd070c4fffb33468976c93baff9493922fb3 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Thu, 8 Sep 2022 23:14:38 +0800
Subject: [PATCH] nios2: Add #undef of MUSL_DYNAMIC_LINKER
Add #undef of MUSL_DYNAMIC_LINKER before #define, to satisfy build checks
when configured with --enable-werror-always.
gcc/ChangeLog
On 2022/8/15 7:15 PM, Chung-Lin Tang wrote:
On 2022/8/15 7:06 PM, Chung-Lin Tang wrote:
I know this is a big pile of yarn wrt how the main program/libgomp/libgfortran
interacts, but it's
finally working. Again tested without regressions. Preparing to commit to
devel/omp/gcc-12, and se
Tested on powerpc64le-linux and x86_64-linux with nvptx offloading, seeking
approval for trunk.
Thanks,
Chung-Lin
From c2fdc31880d2d040822e8abece015c29a6d7b472 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Thu, 1 Sep 2022 05:53:49 -0700
Subject: [PATCH 1/2] libgomp: inline config/linux/ba
On 2022/8/4 9:31 PM, Koning, Paul wrote:
On Aug 4, 2022, at 9:17 AM, Chung-Lin Tang wrote:
On 2022/6/28 10:06 PM, Jakub Jelinek wrote:
On Thu, Jun 23, 2022 at 11:47:59PM +0800, Chung-Lin Tang wrote:
with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:
(1) chunk_s
On 2022/8/15 7:06 PM, Chung-Lin Tang wrote:
I know this is a big pile of yarn wrt how the main program/libgomp/libgfortran
interacts, but it's
finally working. Again tested without regressions. Preparing to commit to
devel/omp/gcc-12, and seeking
approval for mainline when the req
or mainline when the requires patches are in.
Thanks,
Chung-Lin
2022-08-15 Chung-Lin Tang
libgcc/
* Makefile.in (crtoffloadend$(objext)): Add $(PICFLAG) to compile rule.
* offloadstuff.c (GOMP_offload_register_ver): Add declaration of weak
symbol.
(__OFFLOA
_alloc/omp_free/etc.
when 'requires unified_shared_memory' is detected.
Tested on devel/omp/gcc-12. Plans is to commit there soon, but also seeking
approval for mainline
once the requires stuff goes in.
Thanks,
Chung-Lin
2022-08-15 Chung-Lin Tang
libgfortran/ChangeLog:
*
On 2022/6/28 10:06 PM, Jakub Jelinek wrote:
On Thu, Jun 23, 2022 at 11:47:59PM +0800, Chung-Lin Tang wrote:
with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:
(1) chunk_size <= -1: wraps into large unsigned value, seems to work though.
(2) chunk_size == 0: infinit
Hi Jakub,
with the way that chunk_size < 1 is handled for gomp_iter_dynamic_next:
(1) chunk_size <= -1: wraps into large unsigned value, seems to work though.
(2) chunk_size == 0: infinite loop
The (2) behavior is obviously not desired. This patch fixes this by changing
the chunk_size initializ
On 2022/6/9 8:22 PM, Jakub Jelinek wrote:
+ OpenMP 5.2:
+
+ uses_allocators ( modifier : allocator-list )
Please drop the -list above.
+ uses_allocators ( modifier , modifier : allocator-list )
and here too.
Thanks for catching.
+ struct item_tok
+ {
+location_t loc;
+tree
Hi Jakub,
this is v4 of the uses_allocators patch.
On 2022/5/31 6:02 PM, Jakub Jelinek wrote:
The response I got on omp-lang is that it is intentional that in the new
syntax only a single allocator is allowed.
So I'd suggest to implement:
1) if has_modifiers (i.e. certainly new syntax), only all
On 2022/6/6 9:22 下午, Jakub Jelinek wrote:
On Mon, Jun 06, 2022 at 09:19:18PM +0800, Chung-Lin Tang wrote:
On 2022/5/31 6:02 PM, Jakub Jelinek wrote:
5) for C++, we should handle FIELD_DECLs, but it shouldn't be hard, just
look how it is handled for private too
Jakub
On 2022/5/31 6:02 PM, Jakub Jelinek wrote:
5) for C++, we should handle FIELD_DECLs, but it shouldn't be hard, just
look how it is handled for private too
Jakub
About private() for non-static members, is it really working right now?
A simple test:
struct C {
omp_allocator_handle
Hi Jakub,
this is v3 of the uses_allocators patch.
On 2022/5/20 1:46 AM, Jakub Jelinek wrote:
On Tue, May 10, 2022 at 07:29:23PM +0800, Chung-Lin Tang wrote:
@@ -15624,6 +15626,233 @@ c_parser_omp_clause_allocate (c_parser *parser, tree
list)
return nl;
}
+/* OpenMP 5.2
On 2022/5/7 12:40 AM, Tobias Burnus wrote:
Can please also handle the new clause in Fortran's dump-parse-tree.cc?
I did see some split handling in C, but not in Fortran; do you also need
to up update gfc_split_omp_clauses in Fortran's trans-openmp.cc?
Done.
Actually, glancing at the testcas
in a uses_allocator clause", as to mentioned in[1].
This is done during gimplify_scan_omp_clauses.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-May/594039.html
Tested on mainline, please see if this is okay.
Thanks,
Chung-Lin
2022-05-06 Chung-Lin Tang
gcc/c-family/ChangeLog:
probably not a regression, but seeking to commit when stage1 opens.
Thanks,
Chung-Lin
2022-04-01 Chung-Lin Tang
gcc/ChangeLog:
* omp-low.cc (lower_omp_target): Use outer context looked-up 'var' as
argument to lang_hooks.decls.omp_array_data, instead of 'ovar'
Should libgomp behavior be adjusted here, or should SPEC benchmark
source be adjusted?
(The attached patch to adjust libgomp attach behavior has been regtested
without regressions, FWIW)
Thanks,
Chung-Lin
2022-03-09 Chung-Lin Tang
libgomp/ChangeLog:
* target.c (gomp_attach_pointer)
later.
This patch basically just removes the check for static members inside
cp_omp_mappable_type_1, and adjusts a testcase. Not sure if more tests are
needed.
Tested on trunk without regressions, okay when stage1 reopens?
Thanks,
Chung-Lin
2022-03-09 Chung-Lin Tang
gcc/cp/ChangeLog
-ref base-pointer goes down the right path.
This case was encountered when working to make 534.hpgmgfv_t from
SPEChpc 2021 properly compile. Tested without regressions on trunk.
Okay to go in once stage1 opens?
Thanks,
Chung-Lin
2022-02-21 Chung-Lin Tang
gcc/c/ChangeLog:
* c-typec
Ping.
On 2022/1/3 10:15 PM, Chung-Lin Tang wrote:
This issue was triggered after the patch extending syntax for component access
in map clauses
(https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=0ab29cf0bb68960c)
In gimplify_scan_omp_clauses, the case for handling indirect accesses (which
Forgot to attach the patch, here it is :P
On 2022/1/10 10:59 PM, Chung-Lin Tang wrote:
For cases like:
#pragma omp target update from(s[0].a[0:1])
The handling in [c_]finish_omp_clauses was only peeling off ARRAY_REF once
before the loop handling COMPONENT_REF, and snagged when the base of
For cases like:
#pragma omp target update from(s[0].a[0:1])
The handling in [c_]finish_omp_clauses was only peeling off ARRAY_REF once
before the loop handling COMPONENT_REF, and snagged when the base of the
component_ref is an array access. This adds the handling there for both C
and C++ front
-gcn.c (GOMP_OFFLOAD_load_image): Change uses of STRINGX
into XSTRING when looking for GOMP_DEVICE_NUM_VAR in offload image.
* plugin/plugin-nvptx.c (GOMP_OFFLOAD_load_image): Likewise.
From fbb592407c9dd244b4cea086cbb90d7bd0bf60bb Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Tue
7;.
Considering the use of the affinity() clause, which should be specifying the
location of a particular
object in memory, this probably makes sense.
Tested without regressions, seeking approval for trunk.
Thanks,
Chung-Lin
2022-01-03 Chung-Lin Tang
gcc/ChangeLog:
PR middle-e
->a[:N]),
map(t.s[:1])
is not implicitly mapped, thus the entire offloaded access does not work as is.
(fixing that omptests test is out of scope here)
Tested without regressions, okay for trunk?
Thanks,
Chung-Lin
2022-01-03 Chung-Lin Tang
gcc/ChangeLog:
PR middle-end/103
On 2021/12/4 12:47 AM, Jakub Jelinek wrote:
On Tue, Nov 16, 2021 at 08:43:27PM +0800, Chung-Lin Tang wrote:
2021-11-16 Chung-Lin Tang
PR middle-end/92120
gcc/cp/ChangeLog:
...
+ if (allow_zero_length_array_sections)
+ {
+ /* When allowing
This patch by Tobias, fixes a case of setting array low-bounds, found
for particular uses of SOURCE=/MOLD=.
For example:
program A_M
implicit none
real, dimension (:), allocatable :: A, B
allocate (A(0:5))
call Init (A)
contains
subroutine Init ( A )
real, dimension ( 0 : ), intent
Ping.
On 2021/11/4 4:23 PM, Chung-Lin Tang wrote:
Hi Jakub,
As Thomas reported and submitted a patch a while ago:
https://gcc.gnu.org/pipermail/gcc-patches/2019-April/519932.html
https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522738.html
There's an issue with the Fortran front-end
p of the recent also posted C++
PR92120 v5 patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584602.html
Again, tested without regressions (together with the PR92120 patch), awaiting
review.
Thanks,
Chung-Lin
(ChangeLog updated below)
On 2021/5/25 9:36 PM, Chung-Lin Tang wrot
Hi Jakub,
On 2021/6/24 9:15 PM, Jakub Jelinek wrote:
On Fri, Jun 18, 2021 at 10:25:16PM +0800, Chung-Lin Tang wrote:
Note, you'll need to rebase your patch, it clashes with
r12-1768-g7619d33471c10fe3d149dcbb701d99ed3dd23528.
Sorry for that. And sorry for patch review delay.
--- a/gc
Hi Jakub,
On 2021/6/24 11:55 PM, Jakub Jelinek wrote:
On Fri, May 14, 2021 at 09:20:25PM +0800, Chung-Lin Tang wrote:
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index e790f08b23f..69c4a8e0a0a 100644
--- a/gcc/gimplify.c
+++ b/gcc/gimplify.c
@@ -10374,6 +10374,7
ly passed to libgomp during runtime, marks
the passed array with an alignment of 1, which can cause mapping alignment
errors on the offload target.
This patch removes the related fold_convert(build_pointer_type (char_type_node))
calls in fortran/trans-openmp.c, and adds gcc_asserts to ensure pointe
bles there (all initialized) or
say an array and access different elements in the different spots.
Jakub
Thanks, attached is what I finally committed.
Chung-Lin
From 2e4659199e814b7ee0f6bd925fd2c0a7610da856 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Thu, 21 Oct 2021 14:5
r strictly-structured
blocks
has also been changed to "Y" in this patch.
Tested without regressions, is this now okay for trunk?
Thanks,
Chung-Lin
2021-10-20 Chung-Lin Tang
gcc/fortran/ChangeLog:
* decl.c (gfc_match_end): Add COMP_OMP_STRICTLY_STRUCTURED_BLOCK case
toge
uot;
case in Fortran, where the task/target-in_reduction is in another separate
subroutine.
Tested without regressions on trunk, is this okay to commit?
Thanks,
Chung-Lin
2021-10-19 Chung-Lin Tang
gcc/fortran/ChangeLog:
* openmp.c (gfc_match_omp_clause_reduction): Add 'openmp
On 2021/10/14 7:19 PM, Jakub Jelinek wrote:
On Thu, Oct 14, 2021 at 12:20:51PM +0200, Jakub Jelinek via Gcc-patches wrote:
Thinking more about the Fortran case for !$omp sections, there is an
ambiguity.
!$omp sections
block
!$omp section
end block
is clear and !$omp end sections is optional,
o (the new)
COMP_OMP_STRICTLY_STRUCTURED_BLOCK
after the statement is known (I'm not sure if there's a way to 'peek' the next
statement/token in the Fortran FE, open to suggestions on how to better write
this)
Tested with no regressions on trunk, is this okay to commit?
Thanks,
Ch
trunk, is this okay?
(testing for devel/omp/gcc-11 is in progress)
Thanks,
Chung-Lin
2021-09-17 Chung-Lin Tang
gcc/fortran/ChangeLog:
* openmp.c (gfc_match_omp_clause_reduction): Add 'openmp_target' default
false parameter. Add 'always,tofrom' map
after testing. This is not for mainline.
Chung-Lin
From 4e34710679ac084d7ca15ccf387c1b6f1e64c2d1 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Thu, 19 Aug 2021 16:17:02 +0800
Subject: [PATCH] openacc: fix ICE for non-decl expression in non-contiguous
array base-pointer
Currently, we d
From 83177ca9f262b230c892e667ebf685f96a718ec8 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Mon, 9 Aug 2021 08:58:07 +0200
Subject: [PATCH] openmp: Implement omp_get_device_num routine
This patch implements the omp_get_device_num library routine, specified in
OpenMP 5.0.
GOMP_DEVICE_NUM_VAR is a
st_device_num != device_num)
abort ();
..., but here:
+ if (initial_device .and. host_device_num .eq. device_num) stop 3
... shouldn't that be '.not.initial_device', like in:
if (!initial_device && host_device_num == device_num)
abort ();
Yeah, To
On 2021/8/3 8:22 PM, Thomas Schwinge wrote:
Hi Chung-Lin!
On 2021-08-02T21:10:57+0800, Chung-Lin Tang wrote:
--- a/libgomp/fortran.c
+++ b/libgomp/fortran.c
+int32_t
+omp_get_device_num_ (void)
+{
+ return omp_get_device_num ();
+}
Missing 'ialias_redirect (omp_get_devic
On 2021/7/23 6:39 PM, Jakub Jelinek wrote:
On Fri, Jul 23, 2021 at 06:21:41PM +0800, Chung-Lin Tang wrote:
--- a/libgomp/icv-device.c
+++ b/libgomp/icv-device.c
@@ -61,8 +61,17 @@ omp_is_initial_device (void)
return 1;
}
+int
+omp_get_device_num (void)
+{
+ /* By specification, this
On 2021/7/23 7:01 PM, Tobias Burnus wrote:
I personally prefer having:
int initial_dev;
and inside 'omp target' (with 'map(from:initial_dev)'):
initial_device = omp_is_initial_device();
Then the check would be:
if (initial_device && host_device_num != device_num)
abort();
i
ding for amdgcn and nvptx on x86_64-linux host. Okay for trunk?
Thanks,
Chung-Lin
2021-07-23 Chung-Lin Tang
libgomp/ChangeLog
* icv-device.c (omp_get_device_num): New API function, host side.
* fortran.c (omp_get_device_num_): New interface function.
* libgomp-plug
Add "target offload_device_nonshared_as" condition for enabling test.
From e0672017370b9a9362fda52ecffe33d1c9c41829 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Sat, 26 Jun 2021 00:42:58 +0800
Subject: [PATCH] testsuite/101114: Adjust libgomp.c-c++-common/struct-elem-5.c
testcase
The dg
Hi Jakub,
this patch is the "v4" version of my PR92120 patch, v3 was here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570886.html
(there I listed the various patches from devel/omp/gcc-10 branch that was
combined,
which I won't repeat here).
Basically this v4 adds fixes for lambda captu
/target-lambda-2.C: New test.
libgomp/ChangeLog:
* testsuite/libgomp.c++/target-lambda-2.C: New test.
From dbf5d72f4c077215330e5b06fbb9b3311b807c2a Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Thu, 17 Jun 2021 21:53:10 +0800
Subject: [PATCH] Fixes for lambda in offload regions
T
ed is the final patch I pushed.
Thanks,
Chung-Lin
From 275c736e732d29934e4d22e8f030d5aae8c12a52 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Thu, 17 Jun 2021 21:33:32 +0800
Subject: [PATCH] libgomp: Structure element mapping for OpenMP 5.0
This patch implement OpenMP 5.0 requirements of incrementing/decrementing
Hi Jakub,
this is a v3 version of my OpenMP 5.0 structure element mapping patch,
v2 was here: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561139.html
This v3 adds a small bug fix, where the initialization of the refcount didn't
handle all cases, fixed by using gomp_refcount_increment
so you might queued this one later than those for review.
Thanks,
Chung-Lin
2021-05-25 Chung-Lin Tang
gcc/c/ChangeLog:
* c-parser.c (struct omp_dim): New struct type for use inside
c_parser_omp_variable_list.
(c_parser_omp_variable_list): Allow multiple levels of
the main processing in
semantics.c now.
Other parser changes to support '->' in map clauses are also with this patch.
Tested without regressions on x86_64-linux with nvptx offloading, okay for
trunk?
Thanks,
Chung-Lin
2021-05-20 Chung-Lin Tang
gcc/cp/
On 2021/5/17 10:26 PM, Julian Brown wrote:
OK, understood. But, I'm a bit concerned that we're ignoring some
"hidden rules" with regards to OMP pointer clause ordering/grouping that
certain code (at least the bit that creates GOMP_MAP_STRUCT node
groups, and parts of omp-low.c) relies on. I belie
On 2021/5/11 4:57 PM, Julian Brown wrote:
This work-in-progress patch tries to get
GOMP_MAP_ATTACH_ZERO_LENGTH_ARRAY_SECTION to behave more like
GOMP_MAP_ATTACH_DETACH -- in that the mapping is made to form groups
to be processed by build_struct_group/build_struct_comp_map. I think
that's import
Hi Julian,
On 2021/5/15 5:27 AM, Julian Brown wrote:
GCC currently raises a parse error for indirect accesses to struct
members, where the base of the access is a reference to a pointer.
This patch fixes that case.
gcc/cp/
* semantics.c (finish_omp_clauses): Handle components of refer
o regressions on x86_64-linux with nvptx offloading.
Was already pushed to devel/omp/gcc-10 a while ago, asking for approval for
mainline trunk.
Chung-Lin
2021-05-14 Chung-Lin Tang
include/ChangeLog:
* gomp-constants.h (GOMP_MAP_FLAG_SPECIAL_3): Define special bit macro.
On 2021/5/11 11:15 , Thomas Schwinge wrote:
Hi Chung-Lin!
On 2021-05-11T19:28:04+0800, Chung-Lin Tang wrote:
This patch largely implements three pieces of functionality:
(1) Per discussion and clarification on the omp-lang mailing list,
standards conforming behavior for mapping array
oading with no regressions. Pushed to
devel/omp/gcc-10, will
send mainline version of patch later.
Chung-Lin
2021-05-11 Chung-Lin Tang
gcc/c/ChangeLog:
* c-parser.c (struct omp_dim): New struct type for use inside
c_parser_omp_variable_list.
(c_parser_omp_variable_list)
On 2021/5/7 8:35 PM, Thomas Schwinge wrote:
On 2021-05-05T23:17:25+0800, Chung-Lin Tang via
Gcc-patches wrote:
This patch implements relaxing the requirements when a map with the implicit
attribute encounters
an overlapping existing map. [...]
Oh, oh, these data mapping interfaces
[implicit]"
tree printing requires
modifying many gimple scan tests already, so including the test modifications
together seems more
manageable patch-wise.
Tested with no regressions, and pushed to devel/omp/gcc-10. Will be submitting
a mainline trunk version later.
Chung-Lin
2
ed without regressions on x86_64-linux with nvptx offloading,
and pushed to devel/omp/gcc-10.
2021-03-18 Chung-Lin Tang
gcc/cp/ChangeLog:
* cp-tree.h (set_omp_target_this_expr): Delete.
(finish_omp_target_clauses): New prototype.
* lambda.c (lambda_expr_this_capture): Remo
egressions, and pushed to devel/omp/gcc-10.
Chung-Lin
From 4e714eaad985f68533f267b8df2026e5c14d084a Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Thu, 11 Mar 2021 00:31:08 -0800
Subject: [PATCH] Fix template case of non-static member access inside member
functions
Prior patches for C++
00:00:00 2001
From: Chung-Lin Tang
Date: Mon, 8 Mar 2021 15:56:52 +0800
Subject: [PATCH] Arrow operator handling for C front-end in OpenMP map clauses
This patch merges some of the equivalent changes already done for the C++
front-end to the C parts.
2021-03-08 Chung-Lin Tang
gcc/c/ChangeLog:
est.
From 1c3f38b30c1db0aef5ccbf6d20fb5fd13785d482 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Wed, 3 Mar 2021 22:39:10 +0800
Subject: [PATCH] Allow static constexpr fields in mappable types for C++
This patch is a merge of:
https://gcc.gnu.org/legacy-ml/gcc-patches/2020-01/msg01246.html
Static members in general di
committed to devel/omp/gcc-10, the above patch was also re-committed
as well.
Chung-Lin
From da047f63c601118ad875d13929453094acc6c6c9 Mon Sep 17 00:00:00 2001
From: Chung-Lin Tang
Date: Fri, 26 Feb 2021 20:13:29 +0800
Subject: [PATCH] Fix regression of array members in OpenMP map clauses.
Fixed a
ing.
* g++.dg/gomp/target-this-2.C: Likewise.
* g++.dg/gomp/target-this-3.C: Likewise.
* g++.dg/gomp/target-this-4.C: Likewise.
libgomp/ChangeLog:
* testsuite/libgomp.c++/target-23.C: New testcase.
From bf8605f14ec33ea31233a3567f3184fee667b695 Mon Sep 17 00:00:00 2001
1 - 100 of 512 matches
Mail list logo
