eviously
with "alloc", etc. for enter/exit data -- there might still be work to
do there.)
Re-tested with offloading to NVPTX. Does this look OK now?
Thanks,
Julian
commit 377dba3ca7dc6fdf86bdb82936e80100ef2dbf4f
Author: Julian Brown
Date: Mon Oct 17 16:44:31 2022 +
Op
lly make more sense to commit the three patches
squashed together.
Tested with offloading to NVPTX. OK?
Thanks,
Julian
commit abb1e04f9ef93221ecd4292f43cc1ea901843766
Author: Julian Brown
Date: Thu Dec 8 13:31:01 2022 +
OpenMP: implicitly map base pointer for array-section pointer compon
ll the above cases (hopefully
appropriately generalised), at least for Fortran. I haven't attempted
to fix any missing cases for C, for now.
Re-tested with offloading to NVPTX (with a few supporting patches, as
before).
Does this look OK now?
Thanks,
Julian
commit c5e0cb20a07fcce4822dba2731b7af7b372b3376
Author: Julian Bro
> Hi Julian,
>
> I had a first quick lock at this patch, I should have a closer look
> later. However, I stumbled over the following:
>
> On 20.10.22 18:14, Julian Brown wrote:
> > typedef struct gfc_symbol
> > {
> > ...
> >struct gfc_symbol *old_sym
iew or approved but waiting for other patches), i.e.:
OpenMP/OpenACC: Rework clause expansion and nested struct handling
OpenMP/OpenACC: Refine condition for when map clause expansion happens
OpenMP: Pointers and member mappings
and the patch following. OK?
2022-12-06 Julian Brown
g
On Wed, 7 Dec 2022 15:54:42 +0100
Tobias Burnus wrote:
> Hi Julian,
>
> If I understand Deepak's comment (on OpenMP.org's omp-lang list, sorry
> it is a nonpublic list) correctly, the following wording implies that
> a 'from: s.w[z:4]' for a pointer 's.w' also implies a mapping of
> 's.w' - if
er patch
named above.)
2022-11-30 Julian Brown
gcc/
* c-family/c-common.h (c_omp_region_type): Add C_ORT_ACC_TARGET.
(c_omp_address_inspector): Pass c_omp_region_type instead of "target"
bool.
* c-family/c-omp.cc (c_omp_address_inspector::expand_arra
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603793.html
[unreviewed also -- "QoI" improvement to above]
"OpenMP: lvalue parsing for map/to/from clauses (C++)"
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605367.html
[reviewed, but needs a little r
offloading to NVPTX, and bootstrapped.
Julian Brown (~2):
OpenMP/OpenACC: Refine condition for when map clause expansion happens
[...]
OpenMP: C++ "declare mapper" support
--
2.29.2
On Wed, 2 Nov 2022 12:58:37 +0100
Jakub Jelinek via Fortran wrote:
> On Tue, Nov 01, 2022 at 09:50:38PM +0000, Julian Brown wrote:
> > > I think we should figure out when we should temporarily disable
> > > parser->omp_array_section_p = false;
> > > and resto
Hi,
On Tue, 24 May 2022 16:15:31 +0200
Jakub Jelinek via Fortran wrote:
> On Fri, Mar 18, 2022 at 09:26:47AM -0700, Julian Brown wrote:
> > --- a/gcc/cp/parser.cc
> > +++ b/gcc/cp/parser.cc
> > @@ -4266,6 +4266,9 @@ cp_parser_new (cp_lexer *lexer)
> >pars
ap(n) shared(n)").
Tested with offloading to NVPTX. OK?
2022-10-20 Julian Brown
gcc/fortran/
PR fortran/107214
* gfortran.h (gfc_symbol): Add data_mark, dev_mark, gen_mark and
reduc_mark bitfields.
* openmp.cc (resolve_omp_clauses): Use above bitfields t
On Tue, 18 Oct 2022 16:46:07 +0200
Thomas Schwinge wrote:
> Hi Julian!
>
> On 2022-10-14T13:38:56+0000, Julian Brown
> wrote:
> ..., but to my surprised, that did fire in one occasion:
>
> > --- a/libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90
>
.
For now, multiple *constant* array indices are still supported (see
map-arrayofstruct-1.c). That could perhaps be addressed with a follow-up
patch, if necessary.
2022-10-18 Julian Brown
gcc/
* gimplify.cc (extract_base_bit_offset): Add VARIABLE_OFFSET parameter.
(omp_
This patch trivially adds braces and reindents the
OMP_CLAUSE_TO/OMP_CLAUSE_FROM/OMP_CLAUSE__CACHE_ stanza in
c_finish_omp_clause and finish_omp_clause, in preparation for the
following patch (to clarify the diff a little).
2022-09-13 Julian Brown
gcc/c/
* c-typeck.cc
rptr%data
Always moving "[implicit]" full-array mappings after array-section
mappings (without that bit set) means that we'll avoid copying the whole
array unnecessarily -- even in cases where we can't prove that the array
accesses are the same.
Additionally, the next patch in the series
of structs) are not being used for multiple mappings -- for cases where
we can't determine if the elements are the same or not at compile time.
Retested with offloading to NVPTX. OK?
Julian Brown (4):
OpenMP/OpenACC: Reindent TO/FROM/_CACHE_ stanza in
{c_}finish_omp_clause
OpenMP/OpenACC: Rework clause
ut patterns adjusted to compensate.
Tested with offloading to AMD GCN. I will apply shortly (to og12).
2022-10-14 Julian Brown
gcc/
* omp-low.cc (oacc_privatization_candidate_p): Artificial vars are not
privatization candidates.
libgomp/
* testsuite/libgomp.oacc-f
space now or in the future that this patch may be needed for.
Tested with offloading to AMD GCN. I will apply shortly (to og12).
2022-10-14 Julian Brown
gcc/
* config/gcn/gcn.cc (gcn_detect_incoming_pointer_arg): Any pointer
argument forces FLAT addressing mode, not just
poin
: the list is
sorted in libgomp according to the dynamic values of the offsets after
the newly-introduced GOMP_MAP_STRUCT_UNORD node.
This mostly affects arrays of structs indexed by variables in C and C++,
but can also affect derived-type arrays with constant indexes when they
have an array descriptor.
This patch trivially adds braces and reindents the
OMP_CLAUSE_TO/OMP_CLAUSE_FROM/OMP_CLAUSE__CACHE_ stanza in
c_finish_omp_clause and finish_omp_clause, in preparation for the
following patch (to clarify the diff a little).
2022-09-13 Julian Brown
gcc/c/
* c-typeck.cc
y can be proven the same, i.e. if they use the same index variable.
Together with the "unordered struct" patch at the end of this series,
that allows certain types of mapping to work that don't at present.
2022-10-09 Julian Brown
gcc/fortran/
* dependency.cc
OMP_MAP_STRUCT_UNORD.
Tested with offloading to NVPTX. OK?
Julian Brown (4):
OpenMP: Pointers and member mappings
OpenMP/OpenACC: Reindent TO/FROM/_CACHE_ stanza in
{c_}finish_omp_clause
OpenMP/OpenACC: Rework clause expansion and nested struct handling
OpenMP/OpenACC: Unordered/non-const
-patches/2022-September/602504.html
Re-tested with offloading to NVPTX. OK?
Thanks,
Julian
2022-10-01 Julian Brown
gcc/
* gimplify.cc (omp_group_base): Fix IF_PRESENT (no_create)
handling.
---
gcc/gimplify.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, 23 Sep 2022 14:10:51 +0200
Tobias Burnus wrote:
> Hi Julian and Jakub, hi all,
>
> On 23.09.22 09:29, Julian Brown wrote:
> > How about this version? (Re-tested.)
>
> Some more generic (pre)remarks – not affecting the patch code,
> but possibl
On Wed, 28 Sep 2022 17:17:30 +0200
Tobias Burnus wrote:
> On 28.09.22 15:20, Julian Brown wrote:
>
> This patch fixes an ICE when both a complete struct variable and
> components of that struct are mapped on the same directive for
> OpenACC, using a modified version of
function has been added to make sure that the mapping kinds of
the whole struct and the member access are compatible -- conservatively,
so as not to copy more to/from the device than the user expects.
Tested with offloading to NVPTX. OK?
Thanks,
Julian
2022-09-28 Julian Brown
gcc/
PR
and you simply new the
> hash_map when needed the first time and delete it at the end (which
> does nothing if it is NULL).
How about this version? (Re-tested.)
Thanks,
Julian
>From 76ec4e82c3d7918f670d2048ad625c98b3f23921 Mon Sep 17 00:00:00 2001
From: Julian Brown
Date: Tue, 31 May
On Wed, 14 Sep 2022 14:53:54 +0200
Jakub Jelinek wrote:
> On Tue, Sep 13, 2022 at 02:03:16PM -0700, Julian Brown wrote:
> > @@ -3440,6 +3437,50 @@ gfc_trans_omp_clauses (stmtblock_t *block,
> > gfc_omp_clauses *clauses, {
> > if (pointer || (o
On Wed, 14 Sep 2022 14:44:54 +0200
Jakub Jelinek wrote:
> On Tue, Sep 13, 2022 at 02:03:15PM -0700, Julian Brown wrote:
> > This patch moves GOMP_MAP_ATTACH{_ZERO_LENGTH_ARRAY_SECTION} nodes
> > to the end of the clause list, for offload regions. This ensures
> > that
The expected scan dump output for this test will change after the
following patch is committed:
https://gcc.gnu.org/pipermail/gcc-patches/2022-September/601558.html
But for now, this patch reverts to the old expected pattern so the test
passes. I will apply as obvious.
2022-09-15 Julian
These testsuite hunks got left attached to the wrong patch in the series
I just posted. I will apply as obvious.
2022-09-15 Julian Brown
gcc/testsuite/
* c-c++-common/goacc/mdc-2.c: Update expected errors.
* g++.dg/goacc/mdc.C: Likewise.
---
gcc/testsuite/c-c++-common/goacc
On Wed, 14 Sep 2022 16:58:28 +0200
Jakub Jelinek wrote:
> On Tue, Sep 13, 2022 at 02:04:30PM -0700, Julian Brown wrote:
> > This patch implements OpenMP 5.0 "declare mapper" support for C++.
> > This hasn't been fully revised yet following previous review
> &g
On Wed, 14 Sep 2022 15:24:12 +0200
Jakub Jelinek via Fortran wrote:
> On Tue, Sep 13, 2022 at 02:03:18PM -0700, Julian Brown wrote:
> > +class c_omp_address_inspector
> > +{
> > + location_t loc;
> > + tree root_term;
> > + bool indirections;
> > +
er"
definitions), and special-case handling TREE_LIST becomes necessary in
more places, which starts to become unwieldy.
Including this patch to support the surrounding unfinished/FYI patches.
2022-02-18 Julian Brown
gcc/c-family/
* c-omp.cc (c_omp_split_clauses): Support OMP_AR
This patch implements OpenMP 5.0 "declare mapper" support for C++.
This hasn't been fully revised yet following previous review comments,
but I am including it in this series to demonstrate the new approach to
gimplifying map clauses after "declare mapper" instantiation.
The
r) -->
GOMP_MAP_ALLOC tvar%arrptr (the descriptor)
map(tofrom: tvar%arrptr(3:8) -->
GOMP_MAP_TOFROM tvar%arrptr%data(3) (size 8-3+1, etc.)
GOMP_MAP_ALWAYS_POINTER tvar%arrptr%data (bias 3, etc.)
2022-09-13 Julian Brown
gcc/fortran/
* trans-openmp.cc (dependency.h):
This patch changes parsing for OpenMP map clauses in C++ to use the
generic expression parser, hence adds support for parsing general
lvalues (as required by OpenMP 5.0+).
This patch hasn't been fully revised following previous review comments
yet, but I'm including it in support of the following
This patch trivially adds braces and reindents the
OMP_CLAUSE_TO/OMP_CLAUSE_FROM/OMP_CLAUSE__CACHE_ stanza in
c_finish_omp_clause and finish_omp_clause, in preparation for the
following patch (to clarify the diff a little).
2022-09-13 Julian Brown
gcc/c/
* c-typeck.cc
gical case that can otherwise happen with struct sibling-list
handling.
2022-09-13 Julian Brown
gcc/
* gimplify.cc (omp_segregate_mapping_groups): Update comment.
(omp_push_attaches_to_end): New function.
(gimplify_scan_omp_clauses): Use omp_push_attaches_to_end for
e to check if a different clause on the same directive maps
the whole of a struct that we have a component mapping for (for example)
has been outlined, removing a bit of code duplication.
(These changes could be split into different patches if necessary.)
2022-09-13 Julian Brown
gcc/
* g
version was approved already, pending those changes.)
2022-09-13 Julian Brown
gcc/fortran/
* trans-openmp.cc (gfc_trans_omp_clauses): Don't create
GOMP_MAP_TO_PSET mappings for class metadata, nor GOMP_MAP_POINTER
mappings for POINTER_TYPE_P decls.
gcc/
* gimplify.c
h demonstrating a new approach to clause
gimplification is included at the end of this series.
2022-09-13 Julian Brown
gcc/
* gimplify.c (is_or_contains_p, omp_target_reorder_clauses): Delete
functions.
(omp_tsort_mark): Add enum.
(omp_mapping_group): Add str
This patch has been split out from the previous one to avoid a
confusingly-interleaved diff. The two patches will be committed squashed
together.
2022-09-13 Julian Brown
gcc/
* gimplify.c (omp_target_reorder_clauses): Delete.
---
gcc/gimplify.cc | 205
xcept the "trivial" ones) and regression
tested with offloading to NVPTX (up to "OpenMP/OpenACC: Rework clause
expansion and nested struct handling").
Further commentary on individual patches.
Julian Brown (11):
OpenMP 5.0: Clause ordering for OpenMP 5.0 (topol
Hi Jakub,
Thanks for review!
On Tue, 24 May 2022 15:03:07 +0200
Jakub Jelinek via Fortran wrote:
> On Fri, Mar 18, 2022 at 09:24:51AM -0700, Julian Brown wrote:
> > 2021-11-23 Julian Brown
> >
> > gcc/
> > * gimplify.c (is_or_contains_p,
> > om
nodes go off to gimplify for processing.
(This relates to the previous patch in the series.)
We also need to handle module writing and reading for "declare mappers".
This requires an ABI bump that I noticed one of Tobias's patches also
does, so we'll probably need to synchronize
TER tvar%arrptr%data (bias 3, etc.)
OK?
Thanks,
Julian
2022-06-01 Julian Brown
gcc/fortran/
* trans-openmp.cc (dependency.h): Include.
(gfc_trans_omp_array_section): Do not map descriptors here for OpenMP.
(gfc_trans_omp_clauses): Check subcomponent and subarray/
This patch strips NOPs in omp_get_root_term and accumulate_sibling_list
to cover cases that came up writing tests for "omp declare mapper"
functionality. I'll fold this into the originating patch series for
those functions during rework.
2022-06-01 Julian Brown
gcc/
* g
This patch renames the strip_components_and_deref function to better
describe what it does. I'll fold this into the originating patch series
during rework.
2022-06-01 Julian Brown
gcc/
* gimplify.cc (strip_components_and_deref): Rename to...
(omp_get_root_term): This.
---
gcc
introduced by this patch.
OK?
Julian
2022-06-01 Julian Brown
gcc/c-family/
* c-common.h (omp_mapper_list): Add T type parameter.
(c_omp_find_nested_mappers): Update prototype.
* c-omp.cc (c_omp_find_nested_mappers): Use omp_mapper_list.
gcc/c/
*
This patch fixes a minor typo in dump output and a stray unicode character
in a comment.
This one probably counts as obvious.
2022-06-01 Julian Brown
gcc/fortran/
* dump-parse-tree.cc (show_attr): Fix OMP-UDR-ARTIFICIAL-VAR typo.
* trans-openmp.cc (gfc_trans_omp_array_section
offloading to NVPTX.
OK? (Pending rework of the patch series it depends on?)
Thanks,
Julian
Julian Brown (6):
Fortran: Typo/unicode-o fixes
OpenMP: Templatize omp_mapper_list
OpenMP: Rename strip_components_and_deref to omp_get_root_term
OpenMP: Tweak NOP handling in in omp_get
On Thu, 5 May 2022 14:40:38 +0200
Jakub Jelinek via Gcc-patches wrote:
> On Thu, May 05, 2022 at 12:46:29PM +0100, Julian Brown wrote:
> > All the above (at least) has been done as part of the patch series
> > posted here:
> >
> > https://gcc.gnu.org/pipermail/gcc-pat
On Thu, 5 May 2022 10:52:57 +0200
Jakub Jelinek via Gcc-patches wrote:
> On Mon, Feb 21, 2022 at 11:18:57PM +0800, Chung-Lin Tang wrote:
> > as encountered in cases where a program constructs its own
> > deep-copying for arrays-of-pointers, e.g:
> >
> >#pragma omp target enter data
On Mon, 02 May 2022 19:10:41 -0700
Andras Tantos wrote:
> To a previous problem I've asked, Andrew Pinski replied that I should
> merge all *movsi patterns into a single one to avoid (in that case)
> strange deletions in the generated assembly. Is that possible here? It
> appears to me that I
On Tue, 26 Apr 2022 13:12:23 +0200
Thomas Schwinge wrote:
> > @@ -5240,14 +5286,14 @@ gcn_print_lds_decl (FILE *f, tree var)
> >if (size > align && size > 4 && align < 8)
> > align = 8;
> >
> > - machfun->lds_allocated = ((machfun->lds_allocated + align -
> > 1)
> > -
above differences.
(Fortran FE support is TBD.)
2022-03-17 Julian Brown
gcc/c-family/
* c-common.h (omp_mapper_list, c_omp_find_nested_mappers,
c_omp_instantiate_mappers): Add forward declarations/prototypes.
* c-omp.cc (c_omp_find_nested_mappers): New function.
le careful here because OMP_CLAUSE_DEPEND and
OMP_CLAUSE_AFFINITY also use TREE_LIST for their own purposes, and we're
not changing those ones.
No behavioural changes should be introduced by this patch.
2022-03-04 Julian Brown
gcc/c/
* c-parser.cc (c_parser_omp_variable_list): Use OMP_ARR
from instantiated mappers.
This version of the patch improves detection of explicitly-mapped struct
accesses which inhibit implicitly-triggered user-defined mappers for a
target region.
2022-03-17 Julian Brown
gcc/cp/
* cp-gimplify.cc (cxx_omp_finish_mapper_clauses): N
er"
definitions), and special-case handling TREE_LIST becomes necessary in
more places, which starts to become unwieldy.
2022-02-18 Julian Brown
gcc/c-family/
* c-omp.cc (c_omp_split_clauses): Support OMP_ARRAY_SECTION.
gcc/cp/
* parser.cc (cp_parser_omp_var_list_no_open): U
This patch adds support for parsing general lvalues for OpenMP "map"
clauses to the C front-end, similar to the previous patch for C++.
This version of the patch has been adjusted for changes to the address
inspector patch, but is otherwise the same as the last posted version.
2022-03-
).
2022-03-17 Julian Brown
gcc/c-family/
* c-omp.cc (c_omp_address_inspector::map_supported_p): Support
OMP_ARRAY_SECTION.
gcc/cp/
* error.cc (dump_expr): Handle OMP_ARRAY_SECTION.
* parser.cc (cp_parser_new): Initialize parser->omp_array_sectio
This patch relates to OpenMP mapping clauses containing struct members of
reference type, e.g. "mystruct.myref.myptr[:N]". To be able to access
the array slice through the reference in the middle, we need to perform
an attach action for that reference, since it is represented internally
as a
which had become somewhat convoluted. It also now
implements the functionality of the "c_omp_decompose_attachable_address"
function from earlier versions of this patch series.
2022-03-17 Julian Brown
gcc/c-family/
* c-common.h (c_omp_address_inspector): New class.
uot;just a refactor" than the
previously-posted version (hopefully easing review), though several
behavioural changes still remain.
2022-03-17 Julian Brown
gcc/fortran/
* trans-openmp.cc (gfc_trans_omp_clauses): Don't create
GOMP_MAP_TO_PSET mappings for class metadata, nor GOMP
ch has been moved to the front of the patch queue,
thus isn't dependent on any of the following struct-rework patches.
2021-11-23 Julian Brown
gcc/
* gimplify.c (is_or_contains_p, omp_target_reorder_clauses): Delete
functions.
(omp_tsort_mark): Add enum.
(
This patch has been split out from the previous one to avoid a
confusingly-interleaved diff. The two patches should probably be
committed squashed together.
2021-10-01 Julian Brown
gcc/
* gimplify.c (omp_target_reorder_clauses): Delete.
---
gcc/gimplify.cc | 207
mapper" support for C as well as C++.
Further commentary on individual patches. This version of the series has
been tested (offloading to NVPTX) as a whole, for now.
Thanks,
Julian
Julian Brown (11):
OpenMP 5.0: Clause ordering for OpenMP 5.0 (topological sorting by
ba
instantiated mappers.
(C and Fortran FE support are TBD.)
Tested (alongside previous patches) with offloading to NVPTX, and
bootstrapped. Any comments on this general approach? Thoughts on
handling arrays of custom-mapped structs? OK (for stage 1)?
Thanks,
Julian
2022-02-18 Julian B
;arr[:N]") --
similar to the cp/semantics.c changes in the previous patch -- and adds
a couple of new tests.
2021-11-24 Julian Brown
gcc/c/
* c-parser.c (c_parser_postfix_expression_after_primary): Add support
for OpenMP array section parsing.
(c_parser_omp_variable
er"
definitions), and special-case handling TREE_LIST becomes necessary in
more places, which starts to become unwieldy.
2022-02-18 Julian Brown
gcc/c-family/
* c-omp.cc (c_omp_split_clauses): Support OMP_ARRAY_SECTION.
gcc/cp/
* parser.cc (cp_parser_omp_var_list_no_open): U
tle fiddly to get working though,
and isn't unambiguously the right thing to do, so that might need more
thought.
2022-02-18 Julian Brown
gcc/c-family/
* c-omp.cc (c_omp_decompose_attachable_address): Handle more types of
expressions.
gcc/cp/
* error.cc (dump_exp
he C and C++ front-ends to use it.
2021-11-15 Julian Brown
gcc/c-family/
* c-common.h (c_omp_address_inspector): New class.
* c-omp.c (c_omp_address_inspector::init,
c_omp_address_inspector::analyze_components,
c_omp_address_inspector::map_supported_p,
c_omp_ad
ce. The changes as a whole are all relating to increasing
the variety of supported expressions in OpenMP and OpenACC map clauses,
though.
2022-02-18 Julian Brown
gcc/c-family/
* c-common.h (c_omp_decompose_attachable_address): Add prototype.
* c-omp.cc (c_omp_decompose_attachable
This patch has been split out from the previous one to avoid a
confusingly-interleaved diff. The two patches should probably be
committed squashed together.
2021-10-01 Julian Brown
gcc/
* gimplify.c (is_or_contains_p, omp_target_reorder_clauses): Delete.
---
gcc/gimplify.cc | 207
ch has been moved to the front of the patch queue,
thus isn't dependent on any of the following struct-rework patches.
Tested with offloading to NVPTX and bootstrapped. OK (for stage 1)?
Thanks,
Julian
2022-02-18 Julian Brown
gcc/
* gimplify.c (is_or_contains_p, omp_t
so others (mostly Jakub?) have
a chance to look at it and comment on the general approach, etc..
Further commentary on individual patches.
Thanks,
Julian
Julian Brown (8):
OpenMP 5.0: Clause ordering for OpenMP 5.0 (topological sorting by
base pointer)
Remove omp_target_reorder_clause
On Mon, 14 Feb 2022 16:56:35 +0100
Thomas Schwinge wrote:
> Hi Julian!
>
> Two more questions here, in context of <https://gcc.gnu.org/PR102330>
> "[12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932
> since r12-980-g29a2f51806c":
>
> On 2
-- and really only a handful of the
rejected cases would be plausible in the context of an OpenMP "map"
clause anyway, IMO.
OK?
Thanks,
Julian
2021-11-24 Julian Brown
gcc/c-family/
* c-omp.c (c_omp_decompose_attachable_address): Handle
more types of expression
;arr[:N]") --
similar to the cp/semantics.c changes in the previous patch -- and adds
a couple of new tests.
OK?
Thanks,
Julian
2021-11-24 Julian Brown
gcc/c/
* c-parser.c (c_parser_postfix_expression_after_primary): Add support
for OpenMP array section parsing.
he C and C++ front-ends to use it.
(The adjacent "c_omp_decompose_attachable_address" function could also
be moved into the address inspector class, perhaps. That's not been
done yet.)
OK?
Thanks,
Julian
2021-11-15 Julian Brown
gcc/c-family/
* c-common.h (c_omp_address_
sections to use the
soon-to-be-introduced OMP_ARRAY_SECTION tree code throughout instead,
at which point this patch will no longer be necessary.
OK?
Thanks,
Julian
2021-11-15 Julian Brown
gcc/
* tree-pretty-print.c (print_omp_expr, debug_omp_expr): New functions.
* tree-pretty
nce, or the automatically-dereferenced data itself?). An
attach/detach operation is thus synthesised for the reference.
OK?
Thanks,
Julian
2021-10-11 Julian Brown
gcc/cp/
* semantics.c (finish_omp_clauses): Handle reference-typed members.
gcc/
* gimplify.c (bu
I noticed that the test in question now compiles properly, and in fact
runs properly too. Thus it's more useful as a runtime test than a
passing compilation test that otherwise doesn't do much. This patch
moves it to libgomp.
OK?
Thanks,
Julian
2021-10-11 Julian Brown
gcc/testsuite
ata. (The "b" and "c" members would be array
types here, not pointers themselves). In this example the difference
(thus bias encoded in the attach/detach node) will be something like:
(uintptr_t) >a.b[idx].c[0] - (uintptr_t) >a
OK?
Thanks,
Julian
2021-09-29 Julian Brow
This patch fixes parsing for struct components that are array references
in OMP clauses in both the C and C++ front ends.
OK?
Thanks,
Julian
2021-09-29 Julian Brown
gcc/c/
* c-typeck.c (c_finish_omp_clauses): Allow ARRAY_REF components.
gcc/cp/
* semantics.c
are
now shared where appropriate, though OpenACC doesn't do the topological
sorting of nodes (yet?).
OK?
Thanks,
Julian
2021-09-29 Julian Brown
gcc/
* gimplify.c (gimplify_omp_var_data): Remove GOVD_MAP_HAS_ATTACHMENTS.
(extract_base_bit_offset): Remove OFF
This patch has been split out from the previous one to avoid a
confusingly-interleaved diff. The two patches should probably be
committed squashed together.
2021-10-01 Julian Brown
gcc/
* gimplify.c (omp_target_reorder_clauses): Delete.
---
gcc/gimplify.c | 183
rsion of the patch fixes a bug in omp_reorder_mapping_groups,
relative to the last version posted.
OK?
Thanks,
Julian
2021-11-23 Julian Brown
gcc/
* gimplify.c (is_or_contains_p, omp_target_reorder_clauses): Delete
functions.
(omp_tsort_mark): Add enum.
(
parts further.
(This one has already been approved, pending approval of the rest of
the series:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581426.html)
2021-09-29 Julian Brown
gcc/
* gimplify.c (extract_base_bit_offset): Remove BASE_IND, BASE_REF and
OPENMP parameters
enMP,
where possible. (Those are dealt with by later patches in this series.)
OK?
Thanks,
Julian
2021-06-02 Julian Brown
gcc/fortran/
* trans-openmp.c (gfc_trans_omp_clauses): Don't create GOMP_MAP_TO_PSET
mappings for class metadata, nor GOMP_MAP_POINTER mappings
e the code self-document better also.
OK?
Thanks,
Julian
2021-06-02 Julian Brown
gcc/
* gimplify.c (insert_struct_comp_map): Refactor function into...
(build_struct_comp_nodes): This new function. Remove list handling
and improve self-documentation.
(insert_
posted for the og11 branch here (patch & reversion/rework):
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571712.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571884.html
OK?
Thanks,
Julian
2021-06-03 Julian Brown
gcc/
* gimplify.c (extract_base_bit_of
done already in the preceding code.
Previously posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-May/570399.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571711.html (og11)
OK?
Thanks,
Julian
2021-06-02 Julian Brown
gcc/
* gimplify.c (gimplify_scan_omp_clauses
d C++"
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/584445.html
Tested with offloading to NVPTX and bootstrapped. Further commentary
on individual patches. OK?
Thanks,
Julian
Julian Brown (16):
Rewrite GOMP_MAP_ATTACH_DETACH mappings unconditionally
O
This patch adds support for parsing general lvalues for OpenMP "map"
clauses to the C front-end, similar to the previous patch for C++.
OK?
Thanks,
Julian
2021-11-15 Julian Brown
gcc/c/
* c-parser.c (c_parser_postfix_expression_after_primary): Add support
for Op
in the testsuite of course, and newly-added tests), and we
attempt to reject unsupported expressions in order to avoid surprises
for the user.
The intention is to incrementally add support for further kinds of
lvalues on top of this patch.
OK?
Thanks,
Julian
2021-11-15 Julian Brown
gcc/c-family
C++ front-ends to use it.
OK?
Thanks,
Julian
2021-11-15 Julian Brown
gcc/c-family/
* c-common.h (c_omp_address_inspector): New class.
* c-omp.c (c_omp_address_inspector::init,
c_omp_address_inspector::analyze_components,
c_omp_addr
sections to use the
soon-to-be-introduced OMP_ARRAY_SECTION tree code throughout instead,
at which point this patch will no longer be necessary.
OK?
Thanks,
Julian
2021-11-15 Julian Brown
gcc/
* tree-pretty-print.c (print_omp_expr, debug_omp_expr): New functions.
* tree-pretty
101 - 200 of 814 matches
Mail list logo