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 whether it is a
structured or dynamic adjustment at that point. Prob
https://gcc.gnu.org/g:a7578a077ed8b64b94282aa55faf7037690abbc5
commit r14-9991-ga7578a077ed8b64b94282aa55faf7037690abbc5
Author: Chung-Lin Tang
Date: Tue Apr 16 09:03:21 2024 +
OpenACC 2.7: Adjust acc_map_data/acc_unmap_data interaction with reference
counters
This patch
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 !=
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/after "fre1" pass, to verify
removal of a MEM load, also as Thomas suggested.
I have re-tested this
https://gcc.gnu.org/g:ddf852dac2abaca317c10b8323f338123b0585c8
commit r14-9462-gddf852dac2abaca317c10b8323f338123b0585c8
Author: Chung-Lin Tang
Date: Thu Mar 14 10:39:52 2024 +
OpenACC 2.7: front-end support for readonly modifier
This patch implements the front-end support
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,
>
"Minimal OpenACC variant corresponding to PR96668"
> code in 'libgomp/oacc-mem.c:goacc_enter_data_internal' add a safeguard
> that we're not running into 'REFCOUNT_ACC_MAP_DATA' there. I think
> that's currently not (reasonably easily) possible, given that
> 'acc_map_d
e
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_defined_ty
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
ead 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): New funct
On 2023/10/10 11:11 PM, Andrew Stubbs wrote:
> Hi all,
>
> I'm trying to add a new register set to the GCN port, but I've hit a
> problem I don't understand.
>
> There are 256 new registers (each 2048 bit vector register) but the
> register file has to be divided between all the running
using.
FWIW, I've changed to use TREE_NOTHROW instead, if it can give a better sense
of safety :P
I think there's a misunderstanding here anyways: we are not relying on a DECL
marked
TREE_READONLY here. We merely need the OMP_CLAUSE_MAP to be marked as
OMP_CLAUSE_MAP_READONLY == 1.
The other
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 Chung-Lin Tang
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
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)
> &&
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;
>>
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 Tang
gcc/c
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,
initialize
t-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_compute_clause_
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);
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 e
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
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.
(nvptx_expand_bar_red): Ne
ranch, 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_WAIT_H): Remove.
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:4
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]
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 seeking
-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/bar.c into
config/nvptx/bar.c
Preparing
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 requires
nline 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.
(__OFFLOAD_TABLE__)
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:
* m4/matmul_internal.m4: Adjust malloc/free
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
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;
+
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
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
About
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 {
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
also 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:
.
This is 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' from
current
avior 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): When pointer is N
)
but that is for 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
er 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-typeck.cc (handle_om
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
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++
-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
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-end/103643
* gimplify.c
->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 when
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 wrote:
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/gcc/c/c
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
, 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 pointer type.
2021-11-04 Chung-Lin Tang
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:56:20 +0800
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
an FE in general (Tobias plans to work on that later).
I also added another target-in-reduction-2.f90 testcase that tests the
"orphaned"
case in Fortran, where the task/target-in_reduction is in another separate
subroutine.
Tested without regressions on trunk, is this okay to c
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,
Chung-Lin
2021-10-07
, 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 for OMP_LIST_IN_REDUCTION case
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 do
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 macro
nitial_device && host_device_num == device_num)
abort ();
Yeah, Tobias also caught this as well :)
(Also, I'm not familiar with Fortran operator precedence rules, so
probably would put the individual expressions into braces.;-) -- But I
trust you know better than I do, of course
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_device_num
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
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();
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-plugin.h (GOMP_DEVICE_NUM_VAR
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
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
This patch contains:
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
the reference count of a mapped structure at most on
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
ght 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 array and
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/
* cp-tree.h (finish_omp_t
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
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
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
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.
(GOMP_MAP_IMPLICIT): New special map kind bits value.
(GOMP_MAP_FLAG_SPEC
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
h 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): Allow
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
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
2021-05-05 Chung-Lin Tang
include/ChangeLog:
* gomp-constants.h (GOMP_MAP
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): R
, 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++ non-static
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:
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 disqualify
and 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
* 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
From: Chun
1 - 100 of 505 matches
Mail list logo
