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
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
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
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
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:
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
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/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
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
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
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
omp both are regression free with nvptx offloading.
Is this okay for trunk?
Thanks,
Chung-Lin
2020-09-16 Chung-Lin Tang
PR middle-end/92120
gcc/cp/
* cp-tree.h (finish_omp_target): New declaration.
(set_omp_target_this_expr): Likewise.
* lambda.c (lambda_
Ping this patch set.
Thanks,
Chung-Lin
On 2020/9/1 9:16 PM, Chung-Lin Tang wrote:
Hi Jakub,
this patch set implements parts of the target mapping changes introduced
in OpenMP 5.0, mainly the attachment requirements for pointer-based
list items, and the clause ordering.
The first patch here
On 2020/9/29 6:16 PM, Jakub Jelinek wrote:
On Tue, Sep 01, 2020 at 09:16:23PM +0800, Chung-Lin Tang wrote:
this patch set implements parts of the target mapping changes introduced
in OpenMP 5.0, mainly the attachment requirements for pointer-based
list items, and the clause ordering.
The first
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
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)
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'
-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
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
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
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
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
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
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
_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:
*
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
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
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
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/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
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
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
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
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:
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
Hi Thomas,
after your last round of review, I realized that the bulk of the compiler
omp-low work was
simply a case of dumb over-engineering in the wrong direction :P
(although it did painstakingly function correctly)
Instead of making code changes for bias adjustment in the child function code
On 2019/10/8 10:05 PM, Thomas Schwinge wrote:
Hi Chung-Lin!
While we're all waiting for Tom to comment on this;-) -- here's another
item I realized:
On 2019-09-10T19:41:59+0800, Chung-Lin Tang wrote:
The libgomp nvptx plugin changes are also quite contained, with lots of
no
Hi Thomas,
thanks for the first review. I'm still working on another revision,
but wanted to respond to some of the issues you raised first:
On 2019/11/7 8:48 AM, Thomas Schwinge wrote:
(1) The simplest solution: implement a processing which searches and reverts
such
non-contiguous array map en
Thank you Jakub, I'll need some time to look at this.
Thanks.
Chung-Lin
On 2020/10/30 10:05 PM, Jakub Jelinek wrote:
On Mon, Oct 26, 2020 at 09:10:08AM +0100, Jakub Jelinek via Gcc-patches wrote:
Yes, it is a QoI and it is important not to regress about that.
Furthermore, the more we diverge f
Hi Jakub,
here is v3 of this patch set.
On 2020/10/29 7:44 PM, Jakub Jelinek wrote:
+extern void c_omp_adjust_clauses (tree, bool);
So, can you please rename the function to either
c_omp_adjust_target_clauses or c_omp_adjust_mapping_clauses or
c_omp_adjust_map_clauses?
I've renamed it to 'c_o
On 2020/10/29 7:49 PM, Jakub Jelinek wrote:
On Wed, Oct 28, 2020 at 06:32:21PM +0800, Chung-Lin Tang wrote:
@@ -8958,25 +9083,20 @@ gimplify_scan_omp_clauses (tree *list_p, gimple_seq
*pre_p,
/* An "attach/detach" operation on an update directive should
On 2020/10/28 6:33 PM, Chung-Lin Tang wrote:
On 2020/9/1 9:37 PM, Chung-Lin Tang wrote:
his patch is the changes to libgomp and testcases.
There is now (again) a need to indicate OpenACC/OpenMP and
an 'enter data' style directive, so the associated changes to
'enum gomp_map_var
tested for gcc, g++, gfortran (C and Fortran are not really
affected, but since omp-low.c was slightly touched, tested along for
completeness)
and libgomp on x86_64-linux with nvptx offloading, all without regressions.
Is this okay for trunk?
Thanks,
Chung-Lin
2020-11-13 Chung-Lin Ta
interferes" with our installed-mode
testing.
Also, if this does work, then other library testsuites (e.g. libatomic.exp)
might
also need considering updating, I think.
Thanks,
Chung-Lin
2020-01-14 Chung-Lin Tang
* Makefile.tpl (NORMAL_TARGET_EXPORTS): Add export of
SYSROOT_C
Hi Jakub, Thomas,
We had a customer with a C++ program using GPU offloading failing to compile
due to the code's extensive use of 'static constexpr' in its many template
classes (code was using OpenMP, but OpenACC is no different)
While the FE should ensure that no static members should exist for
Hi Maciej,
sorry for the late reply.
On 2020/2/1 5:46 AM, Maciej W. Rozycki wrote:
On Tue, 21 Jan 2020, Maciej W. Rozycki wrote:
I'll give your proposal a shot and I'm lucky enough to have a build
configuration where I can have no compiler preinstalled, so at least I can
check if testing wit
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
On 2019/12/10 12:04 AM, Julian Brown wrote:
I'm citing below the changes introducing 'gomp_remove_var_async',
modelled similar to the existing 'gomp_unmap_vars_async'.
Also for both these, do I understand correctly, that it's actually not
the 'gomp_unref_tgt' that needs to be "delayed" via
'goa
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
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
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
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/
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
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
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
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,
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
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
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
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
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
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/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
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.
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
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
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
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 '&&
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
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,
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
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):
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
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
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
Ping.
BTW, the SC has approved the Nios II port already:
http://gcc.gnu.org/ml/gcc/2013-07/msg00434.html
The port is still awaiting technical review.
Thanks,
Chung-Lin
On 13/7/14 下午3:54, Chung-Lin Tang wrote:
> Hi, the last ping of the Nios II patches was:
> http://gcc.gnu.org/ml/gcc-p
Ping.
On 13/8/20 10:57 AM, Chung-Lin Tang wrote:
> Ping.
>
> BTW, the SC has approved the Nios II port already:
> http://gcc.gnu.org/ml/gcc/2013-07/msg00434.html
>
> The port is still awaiting technical review.
>
> Thanks,
> Chung-Lin
>
> On 13/7/14 下午3:54,
This patch set has been committed, thanks to all maintainers who
reviewed the respective parts.
Thanks,
Chung-Lin
Full ChangeLog:
2012-10-11 Chung-Lin Tang
* builtins.c (expand_builtin_thread_pointer): New.
(expand_builtin_set_thread_pointer): New.
(expand_builtin
On 2012/10/12 06:55 AM, Oleg Endo wrote:
> This broke the recently added thread pointer built-ins on SH, but I was
> prepared for that, so no problem here. The attached patch is a straight
> forward fix.
>
> However, with the patch applied I get an ICE on one of the SH thread
> pointer tests: gc
On 12/9/27 6:25 AM, Janis Johnson wrote:
> On 09/26/2012 01:58 AM, Chung-Lin Tang wrote:
>
> +/* { dg-do compile } */
> +/* { dg-options "-mthumb -O1 -march=armv5te -fno-omit-frame-pointer
> -fno-forward-propagate" } */
> +/* { dg-require-effective-target arm_thumb1
Hi Sterling,
the last thread pointer builtin changes left an unused 'arg' variable in
xtensa_expand_builtin(), which triggered a new warning. Thanks to
Jan-Benedict for testing this. Attached patch was committed as obvious.
Thanks,
Chung-Lin
* config/xtensa/xtensa.c (xtensa_expand_builtin
On 2013/10/6 05:57 PM, Richard Sandiford wrote:
>> > But case 16 is different.
>> > This case is only produced at prologue/epilogue phase, using a temporary
>> > register $r15 to hold a large constant for adjusting stack pointer.
>> > Since prologue/epilogue is after split1/split2 phase, we can on
On 2013/10/6 下午 06:33, Richard Sandiford wrote:
> Chung-Lin Tang writes:
>> On 2013/10/6 05:57 PM, Richard Sandiford wrote:
>>>>> But case 16 is different.
>>>>> This case is only produced at prologue/epilogue phase, using a temporary
>>>>>
On 2016/1/20 09:17 PM, Bernd Schmidt wrote:
> On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:
>> * omp-low.c (scan_sharing_clauses): Call add_local_decl() for
>> use_device/use_device_ptr variables.
>
> It looks vaguely plausible, but if everything is part of the host
&
On 2016/1/22 12:32 AM, Jakub Jelinek wrote:
> On Thu, Jan 21, 2016 at 10:22:19PM +0800, Chung-Lin Tang wrote:
>> On 2016/1/20 09:17 PM, Bernd Schmidt wrote:
>>> On 01/05/2016 02:15 PM, Chung-Lin Tang wrote:
>>>> * omp-low.c (scan_sharing_clauses): Call add_local_
On 2016/1/25 7:06 PM, Jakub Jelinek wrote:
> The following ICEs without the patch and works with it, so I think it is
> better:
>
> 2016-01-25 Jakub Jelinek
>
> * omp-low.c (lower_omp_target) : Set
> DECL_VALUE_EXPR of new_var even for the non-array case. Look
> through DECL
Ping.
On 2013/11/26 02:45 PM, Chung-Lin Tang wrote:
> Hi Bernd,
> I've updated the patch again, please see if it looks fit for approval
> now. Including ChangeLog again for completeness.
>
> Thanks,
> Chung-Lin
>
> 2013-11-26 Chung-Lin Tang
&
Ping x2.
On 2013/12/5 12:19 PM, Chung-Lin Tang wrote:
> Ping.
>
> On 2013/11/26 02:45 PM, Chung-Lin Tang wrote:
>> Hi Bernd,
>> I've updated the patch again, please see if it looks fit for approval
>> now. Including ChangeLog again for completeness.
>>
&g
On 2013/7/14 09:27 PM, Joseph S. Myers wrote:
> On Sun, 14 Jul 2013, Chung-Lin Tang wrote:
>
>> Original patch posted as part of Nios II patches:
>> http://gcc.gnu.org/ml/gcc-patches/2013-04/msg01087.html
>>
>> This patch is to allow hexadecimal numbers to be us
Ping x3.
On 13/12/10 12:57 PM, Chung-Lin Tang wrote:
> Ping x2.
>
> On 2013/12/5 12:19 PM, Chung-Lin Tang wrote:
>> Ping.
>>
>> On 2013/11/26 02:45 PM, Chung-Lin Tang wrote:
>>> Hi Bernd,
>>> I've updated the patch again, please see if it looks f
On 13/12/23 12:54 AM, Chung-Lin Tang wrote:
>> Other than these two, I think this can go in.
>> > Bernd
> Attached is the updated patch for the compiler.
>
> Since Bernd is a Global Reviewer, am I clear for committing the port
> now? (including the testsuite and libg
On 2013/12/28 02:29 PM, Chung-Lin Tang wrote:
> On 13/12/23 12:54 AM, Chung-Lin Tang wrote:
>>> Other than these two, I think this can go in.
>>>> Bernd
>> Attached is the updated patch for the compiler.
>>
>> Since Bernd is a Global Reviewer, am I clear
On 2014/1/1 02:45 PM, Mike Stump wrote:
> On Dec 31, 2013, at 12:26 PM, Jan-Benedict Glaw wrote:
>> On Tue, 2013-12-31 15:24:52 +0800, Chung-Lin Tang
>> wrote:
>>> The nios2 port was just committed. Thanks to all that gave time and
>>> effort to review this.
&
similar fields in struct loop, namely
'safelen' and 'can_be_parallel', used by OMP simd safelen and GRAPHITE
respectively.
The intention and/or setting of these fields are all a bit different, so I've
decided to add a new bool for OpenACC.
Tested and committed to gomp-
On 15/7/14 3:00 PM, Jakub Jelinek wrote:
> On Tue, Jul 14, 2015 at 01:46:04PM +0800, Chung-Lin Tang wrote:
>> this patch provides a 'bool independent' field in struct loop, which
>> will be switched on by an "independent" clause in a #pragma acc loop
>> d
The header was used back when Nios II Linux used a syscall
cmpxchg,
long since removed and actually never got into the FSF trunk.
Patch removes the #include, and the following error code #defines which are
all no longer used. Committed.
Chung-Lin
2015-07-22 Chung-Lin Tang
* config
goacc_runtime_initialize() instead, thereby ensuring the init order.
libgomp testsuite was re-run without regressions, okay for trunk?
Thanks,
Chung-Lin
2015-09-18 Chung-Lin Tang
PR libgomp/67141
* oacc-int.h (goacc_host_init): Add declaration.
* oacc-host.c
On 2015/9/18 04:02 PM, Jakub Jelinek wrote:
> On Fri, Sep 18, 2015 at 03:41:30PM +0800, Chung-Lin Tang wrote:
>> this patch fixes the uninitialized acc_device_lock mutex situation
>> reported in PR 67141. The patch attached on the bugzilla page
>> tries to solve it by construc
1 - 100 of 512 matches
Mail list logo
