809e2a0248e6fad1e8336b4a883a729017cc62e5 Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Wed, 24 Apr 2024 20:29:14 +0200
Subject: [PATCH] amdgcn: Add gfx90c target
Add support for gfx90c GCN5 APU integrated graphics devices.
The LLVM AMDGPU documentation does not list those devices as
Ping.
The Linaro CI has kindly pointed me to two test regressions that I had
missed. I have adjust the test expectations in the updated patch which I
have attached.
Frederik
On 28.02.24 8:32 PM, Frederik Harwath wrote:
Hi,
this patch implements a warning about (some simple cases of direct
u and not observed any
regressions.
Is it ok to commit this?
Best regards,
Frederik
From 4944a9f94bcda9907e0118e71137ee7e192657c2 Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Tue, 27 Feb 2024 21:07:00 +
Subject: [PATCH] OpenMP: warn about iteration var modifications in loop bod
The index variable initialization for the 'omp unroll'
directive with 'full' clause got lost and the testsuite
did not catch it.
Add the initialization and add -Wall to some tests
to detect uninitialized variable uses and other
potential problems in the code generation.
gcc/ChangeLog:
*
gcc/ChangeLog:
* omp-transform-loops.cc (print_optimized_unroll_partial_msg):
Output "omp unroll partial" instead of "omp unroll auto".
(optimize_transformation_clauses): Likewise.
libgomp/ChangeLog:
* testsuite/libgomp.fortran/loop-transforms/unroll-6.f90: Adjust
gcc/ChangeLog:
* omp-transform-loops.cc (gomp_for_number_of_iterations):
Always compute "final - init" and do not take absolute value.
Identify non-iterating and infinite loops for constant init,
final, step values for better diagnostic messages, consistent
Hi,
the following patches contain some fixes from the devel/omp/gcc-13 branch
to the patches that implement the OpenMP 5.1. loop transformation directives
which I have posted in March 2023.
Frederik
Frederik Harwath (4):
openmp: Fix loop transformation tests
openmp: Fix initialization for
libgomp/ChangeLog:
* testsuite/libgomp.fortran/loop-transforms/tile-2.f90: Add reduction
clause.
* testsuite/libgomp.fortran/loop-transforms/unroll-1.f90: Initialize
var.
* testsuite/libgomp.fortran/loop-transforms/unroll-simd-1.f90: Add
reduction
and initializat
Hi Jakub,
On 16.05.23 13:00, Jakub Jelinek wrote:
On Tue, May 16, 2023 at 11:45:16AM +0200, Frederik Harwath wrote:
The place where different compilers implement the loop transformations
was discussed in an OpenMP loop transformation meeting last year. Two
compilers (another one and GCC with
Hi Jakub,
On 15.05.23 12:19, Jakub Jelinek wrote:
On Fri, Mar 24, 2023 at 04:30:38PM +0100, Frederik Harwath wrote:
this patch series implements the OpenMP 5.1 "unroll" and "tile"
constructs. It includes changes to the C,C++, and Fortran front end
for parsing the new
= 0;
return D_2064;
}
(Strictly speaking, the OMP_FOR is represented as a gomp_for at this point,
but this does not really matter.)
Can I commit the patch?
Best regards,
Frederik
From 8af01114c295086526a67f56f6256fc945b1ccb5 Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Wed, 19 Apr 2023 13
ay, even with 100 of repeated test executions ;-).
Best regards,
Frederik
From 3f471ed293d2e97198a65447d2f0d2bb69a2f305 Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Thu, 6 Apr 2023 14:52:07 +0200
Subject: [PATCH] openmp: Fix loop transformation tests
libgomp/ChangeLog:
* testsuite/
Add the parsing of loop transformations on inner loops of a loop-nest.
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_nested_loop_transform_clauses):
Add argument for the level of loop-nest at which the clauses
appear, ...
(c_parser_omp_tile): ... adjust use here,
So far the implementation of the "omp tile" and "omp unroll"
directives restricted their use to the outermost loop of a loop-nest.
This commit changes the Fortran front end to parse and verify the
directives on inner loops. The transformation clauses are extended to
carry the information about the
This commit adds the C and C++ front end support for the "omp tile"
directive.
gcc/c-family/ChangeLog:
* c-omp.cc (c_omp_directives): Add PRAGMA_OMP_TILE.
* c-pragma.cc (omp_pragmas_simd): Likewise.
* c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_TILE.
(enum pragma
This commit implements the Fortran front end support for the "omp
tile" directive and the corresponding middle end transformation.
gcc/fortran/ChangeLog:
* gfortran.h (enum gfc_statement): Add ST_OMP_TILE, ST_OMP_END_TILE.
(enum gfc_exec_op): Add EXEC_OMP_TILE.
(loop_trans
OMP_CLAUSE_TILE will be used for the OpenMP 5.1 loop transformation
construct "omp tile".
gcc/ChangeLog:
* tree-core.h (enum omp_clause_code): Rename OMP_CLAUSE_TILE.
* tree.h (OMP_CLAUSE_TILE_LIST): Rename to ...
(OMP_CLAUSE_OACC_TILE_LIST): ... this.
(OMP_CLAUSE_
This commit implements the C and the C++ front end changes to support
the "omp unroll" directive. The execution of the loop transformation
relies on the pass that has been added as a part of the earlier
Fortran patch.
gcc/c-family/ChangeLog:
* c-gimplify.cc (c_genericize_control_stmt): H
with
both nvptx-none and amdgcn-amdhsa offloading.
Best regards,
Frederik
Frederik Harwath (7):
openmp: Add Fortran support for "omp unroll" directive
openmp: Add C/C++ support for "omp unroll" directive
openacc: Rename OMP_CLAUSE_TILE to OMP_CLAUSE_OACC_TILE
openmp: A
Adjust the testsuite to changed expectations with the new
Graphite-based "kernels" handling.
libgomp/ChangeLog:
* testsuite/libgomp.oacc-c++/privatized-ref-2.C: Adjust.
* testsuite/libgomp.oacc-c++/privatized-ref-3.C: Adjust.
* testsuite/libgomp.oacc-c-c++-common/acc_prof
gcc/ChangeLog:
* omp-low.c (lower_oacc_reductions): Only create a reference
if variable has pointer type.
---
gcc/omp-low.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/gcc/omp-low.c b/gcc/omp-low.c
index ae5cdfc5e260..2b8b848ec03a 100644
--- a/gcc/omp-
From: Tobias Burnus
Replacing of a by-reference variable in a private clause by a local variable
makes sense; however, for arrays, the size is not directly known by the type.
This causes an ICE via create_tmp_var which indirectly invokes
force_constant_size in this case - but the latter only hand
From: Tobias Burnus
Nearly all variable mapping is moved from 'kernels' to a surrounding
'data kernels' and then 'force_present' mapped for the 'kernels'. However, as
libgomp.oacc-c-c++-common/declare-vla.c shows, moving 'int i, N' will fail as
there is a special case for is_gimple_reg in mapping
gcc/ChangeLog:
* gimplify.c (gimplify_omp_for): Enable localization on
"kernels" regions.
(gimplify_omp_workshare): Likewise.
---
gcc/gimplify.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index bf37388f
From: Julian Brown
gcc/
* gimplify.c (localize_reductions): Rewrite references for
OMP_CLAUSE_PRIVATE also.
libgomp/
* testsuite/libgomp.oacc-fortran/privatized-ref-1.f95: New test.
* testsuite/libgomp.oacc-c++/privatized-ref-2.C: New test.
From: Julian Brown
gcc/
* gimplify.c (gimplify_omp_for): Use for_stmt in call to
localize_reductions.
---
gcc/gimplify.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 04ffbc256442..daa69ccf6202 100644
--- a/gcc
From: Julian Brown
gcc/
* gimplify.c (gimplify_omp_workshare): Use OMP_CLAUSES, OMP_BODY
instead of OMP_TARGET_CLAUSES, OMP_TARGET_BODY.
---
gcc/gimplify.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/gcc/gimplify.c b/gcc/gimplify.c
index 9a4331c7
From: Julian Brown
gcc/
* gimplify.c (privatize_reduction): New struct.
(localize_reductions_r, localize_reductions): New functions.
(gimplify_omp_for): Call localize_reductions.
(gimplify_omp_workshare): Likewise.
* omp-low.c (lower_oacc_reductions
It seems that the check that rejects loops without data references is
only included to avoid handling non-profitable loops. Including those
loops in Graphite's analysis enables more consistent diagnostic
messages in OpenACC "kernels" code and does not introduce any
testsuite regressions. If execu
The find_common_loop function is used in Graphite to obtain a common
super-loop of all loops inside a SCoP. The function is applied to the
loop of the destination block of the edge that leads into the SESE
region and the loop of the source block of the edge that exits the
region. The exit block i
The default values of some parameters that restrict Graphite's
resource usage are too low for many OpenACC codes. Furthermore,
exceeding the limits does not alwas lead to user-visible diagnostic
messages.
This commit increases the parameter values on OpenACC functions. The
values were chosen to
The additional dependences introduced by partial redundancy
elimination proper and by the code hoisting step of the pass very
often cause Graphite to fail on OpenACC functions. On the other hand,
the pass can also enable the analysis of OpenACC loops (cf. e.g. the
loop-auto-transfer-4.f90 testcase)
The loop invariant motion pass correctly refuses to move statements
out of a loop if any other statement in the loop is unanalyzable. The
pass does not know how to handle the OpenACC internal function calls
which was not necessary until recently when the OpenACC device
lowering pass was moved to a
From: Andrew Stubbs
This commit adds the code generation for the runtime alias checks for
OpenACC loops that have been analyzed by Graphite. The runtime alias
check condition gets generated in Graphite. It is evaluated by the
code generated for the IFN_GOACC_LOOP internal function calls. If
ali
This commit concerns loops in OpenACC "kernels" region that have been marked
up with an explicit "independent" clause by the user, but for which Graphite
found data dependences. A discussion on the private internal OpenACC mailing
list suggested that warning the user about the dependences woud be
From: Andrew Stubbs
Address PR90591 "Avoid unnecessary data transfer out of OMP
construct", for simple (but common) cases.
This commit adds a pass that optimizes data mapping clauses.
Currently, it can optimize copy/map(tofrom) clauses involving scalars
to copyin/map(to) and further to "private"
Commit 89f4f339130c ("For 'OMP_CLAUSE' in 'dump_generic_node', dump
the whole OMP clause chain") changed the dumping behavior for
OMP_CLAUSEs. The old behavior is required for a follow-up
commit ("openacc: Add data optimization pass") that optimizes single
OMP_CLAUSEs.
gcc/ChangeLog:
* t
With the old "kernels" handling, unparallelized regions would
get executed with 1x1x1 partitioning even if the user provided
explicit num_gangs, num_workers clauses etc.
This commit restores this behavior by removing unused partitioning
after assigning the parallelism dimensions to loops.
gcc/Cha
gcc/ChangeLog:
* graph.c (oacc_get_fn_attrib): New declaration.
(find_loop_location): New declaration.
(draw_cfg_nodes_for_loop): Print value of the
can_be_parallel flag at the top of loops in OpenACC
functions.
---
gcc/graph.c | 35
Graphite rejects a SCoP if it contains a pair of data references for
which it cannot determine statically if they may alias. This happens
very often, for instance in C code which does not use explicit
"restrict". This commit adds the possibility to analyze a SCoP
nevertheless and perform an alias
Move this function from tree-loop-distribution.c to tree-data-ref.c
and make it non-static to enable its use from other parts of GCC.
gcc/ChangeLog:
* tree-loop-distribution.c (data_ref_segment_size): Remove function.
(latch_dominated_by_data_ref): Likewise.
(compute_alias_
The OpenACC device lowering pass must run after the Graphite pass to
allow for the use of Graphite for automatic parallelization of kernels
regions in the future. Experimentation has shown that it is best,
performancewise, to run pass_oacc_device_lower together with the
related passes pass_oacc_loo
gcc/ChangeLog:
* graphite-sese-to-poly.c (build_poly_sr_1): Fix a typo and
a reference to a variable which does not exist.
* graphite-isl-ast-to-gimple.c (gsi_insert_earliest): Fix typo
in comment.
---
gcc/graphite-isl-ast-to-gimple.c | 2 +-
gcc/graphite-sese-to-p
The SSA names for which this function gets used are always SCoP
parameters and hence "isl_id_for_parameter" is a better name. It also
explains the prefix "P_" for those names in the ISL representation.
gcc/ChangeLog:
* graphite-sese-to-poly.c (isl_id_for_ssa_name): Rename to ...
The Fortran front end presently linearizes accesses to
multi-dimensional arrays by combining the indices for the various
dimensions into a series of explicit multiplies and adds with
refactoring to allow CSE of invariant parts of the computation.
Unfortunately this representation interferes with Gr
Extend dump output to make understanding why Graphite rejects to
include a loop in a SCoP easier (for GCC developers).
ChangeLog:
* graphite-scop-detection.c (scop_detection::can_represent_loop):
Output reason for failure to dump file.
(scop_detection::harmful_loop_in_regi
From: Sandra Loosemore
OpenACC loop semantics require that the loop bound be computable
before entering the loop, rather than the C/C++ semantics where the
end test is evaluated on every iteration. Formerly the kernels loop
annotater permitted only constants and variables not modified in the
loo
From: Sandra Loosemore
The code for identifying annotatable loops in OpenACC kernels regions
previously looked for the loop variable as the left-hand side of the
comparison in the loop end test. However, front end optimizations
sometimes switch the sense of the comparison, making this method
unr
From: Sandra Loosemore
Several of the Fortran tests for kernels loop annotation were failing
due to changes in the formatting of "acc loop" constructs in the dump
file. Now the "auto" clause appears first, instead of after "private".
2020-08-23 Sandra Loosemore
gcc/testsuite/
From: Sandra Loosemore
This tweak to the OpenACC kernels loop annotation relaxes the
restrictions on function calls in the loop body. Normally calls to
functions not explicitly marked with a parallelism attribute are not
permitted, but C/C++ builtins and Fortran intrinsics have known
semantics s
From: Sandra Loosemore
Normally explicit loop directives in a kernels region inhibit
automatic annotation of other loops in the same nest, on the theory
that users have indicated they want manual control over that section
of code. However there seems to be an expectation in user code that
the co
From: Sandra Loosemore
Normally explicit loop directives in a kernels region inhibit
automatic annotation of other loops in the same nest, on the theory
that users have indicated they want manual control over that section
of code. However there seems to be an expectation in user code that
the co
From: Sandra Loosemore
2020-08-19 Sandra Loosemore
gcc/
* tree.h (OACC_LOOP_COMBINED): New.
gcc/c/
* c-parser.c (c_parser_oacc_loop): Set OACC_LOOP_COMBINED.
gcc/cp/
* parser.c (cp_parser_oacc_loop): Set OACC_LOOP_COMBINED.
gcc/fortra
From: Sandra Loosemore
The g++ front end wraps the array length and low_bound values in
NON_LVALUE_EXPR, causing the subsequent tests for INTEGER_CST to fail.
The test case c-c++-common/goacc/kernels-loop-annotation-1.c was
tickling this bug and giving bogus errors in g++ because it was falling
t
From: Sandra Loosemore
2020-03-27 Sandra Loosemore
gcc/testsuite/
* gfortran.dg/goacc/classify-kernels-unparallelized.f95: Adjust
line numbering.
* gfortran.dg/goacc/classify-kernels.f95: Likewise.
* gfortran.dg/goacc/kernels-decompose-2.f95: Add
From: Sandra Loosemore
This patch implements the Fortran support for adding "#pragma acc loop auto"
annotations to loops in OpenACC kernels regions. It implements the same
-fopenacc-kernels-annotate-loops and -Wopenacc-kernels-annotate-loops options
that were previously added (and documented) fo
From: Sandra Loosemore
This patch detects loops in kernels regions that are candidates for
parallelization, and adds "#pragma acc loop auto" annotations to them.
This annotation is controlled by the -fopenacc-kernels-annotate-loops
option, which is enabled by default. -Wopenacc-kernels-annotate-
From: Sandra Loosemore
2020-03-27 Sandra Loosemore
gcc/testsuite/
* c-c++-common/goacc/kernels-decompose-2.c: Add
-fno-openacc-kernels-annotate-loops.
---
gcc/testsuite/c-c++-common/goacc/kernels-decompose-2.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/te
can discuss some of the
changes before they can be considered for inclusion in GCC during the
next stage 1.
Best regards,
Frederik
Andrew Stubbs (2):
openacc: Add data optimization pass
openacc: Add runtime a lias checking for OpenACC kernels
Frederik Harwath (20):
Fortran: Delineariz
It seems that the check that rejects loops without data references is
only included to avoid handling non-profitable loops. Including those
loops in Graphite's analysis enables more consistent diagnostic
messages in OpenACC "kernels" code and does not introduce any
testsuite regressions. If execu
The find_common_loop function is used in Graphite to obtain a common
super-loop of all loops inside a SCoP. The function is applied to the
loop of the destination block of the edge that leads into the SESE
region and the loop of the source block of the edge that exits the
region. The exit block i
The default values of some parameters that restrict Graphite's
resource usage are too low for many OpenACC codes. Furthermore,
exceeding the limits does not alwas lead to user-visible diagnostic
messages.
This commit increases the parameter values on OpenACC functions. The
values were chosen to
The additional dependences introduced by partial redundancy
elimination proper and by the code hoisting step of the pass very
often cause Graphite to fail on OpenACC functions. On the other hand,
the pass can also enable the analysis of OpenACC loops (cf. e.g. the
loop-auto-transfer-4.f90 testcase)
The loop invariant motion pass correctly refuses to move statements
out of a loop if any other statement in the loop is unanalyzable. The
pass does not know how to handle the OpenACC internal function calls
which was not necessary until recently when the OpenACC device
lowering pass was moved to a
This commit concerns loops in OpenACC "kernels" region that have been marked
up with an explicit "independent" clause by the user, but for which Graphite
found data dependences. A discussion on the private internal OpenACC mailing
list suggested that warning the user about the dependences woud be
From: Andrew Stubbs
Address PR90591 "Avoid unnecessary data transfer out of OMP
construct", for simple (but common) cases.
This commit adds a pass that optimizes data mapping clauses.
Currently, it can optimize copy/map(tofrom) clauses involving scalars
to copyin/map(to) and further to "private"
From: Andrew Stubbs
This commit adds the code generation for the runtime alias checks for
OpenACC loops that have been analyzed by Graphite. The runtime alias
check condition gets generated in Graphite. It is evaluated by the
code generated for the IFN_GOACC_LOOP internal function calls. If
ali
Commit 89f4f339130c ("For 'OMP_CLAUSE' in 'dump_generic_node', dump
the whole OMP clause chain") changed the dumping behavior for
OMP_CLAUSEs. The old behavior is required for a follow-up
commit ("openacc: Add data optimization pass") that optimizes single
OMP_CLAUSEs.
gcc/ChangeLog:
* t
Add some copies of tests to continue covering the old "parloops"-based
"kernels" implementation - until it gets removed from GCC - and
add further tests for the new Graphite-based implementation.
libgomp/ChangeLog:
* testsuite/libgomp.oacc-fortran/parallel-loop-auto-reduction-2.f90:
With the old "kernels" handling, unparallelized regions would
get executed with 1x1x1 partitioning even if the user provided
explicit num_gangs, num_workers clauses etc.
This commit restores this behavior by removing unused partitioning
after assigning the parallelism dimensions to loops.
gcc/Cha
gcc/ChangeLog:
* graph.c (oacc_get_fn_attrib): New declaration.
(find_loop_location): New declaration.
(draw_cfg_nodes_for_loop): Print value of the
can_be_parallel flag at the top of loops in OpenACC
functions.
---
gcc/graph.c | 35
Graphite rejects a SCoP if it contains a pair of data references for
which it cannot determine statically if they may alias. This happens
very often, for instance in C code which does not use explicit
"restrict". This commit adds the possibility to analyze a SCoP
nevertheless and perform an alias
Move this function from tree-loop-distribution.c to tree-data-ref.c
and make it non-static to enable its use from other parts of GCC.
gcc/ChangeLog:
* tree-loop-distribution.c (data_ref_segment_size): Remove function.
(latch_dominated_by_data_ref): Likewise.
(compute_alias_
gcc/ChangeLog:
* graphite-sese-to-poly.c (build_poly_sr_1): Fix a typo and
a reference to a variable which does not exist.
* graphite-isl-ast-to-gimple.c (gsi_insert_earliest): Fix typo
in comment.
---
gcc/graphite-isl-ast-to-gimple.c | 2 +-
gcc/graphite-sese-
The SSA names for which this function gets used are always SCoP
parameters and hence "isl_id_for_parameter" is a better name. It also
explains the prefix "P_" for those names in the ISL representation.
gcc/ChangeLog:
* graphite-sese-to-poly.c (isl_id_for_ssa_name): Rename to ...
The OpenACC device lowering pass must run after the Graphite pass to
allow for the use of Graphite for automatic parallelization of kernels
regions in the future. Experimentation has shown that it is best,
performancewise, to run pass_oacc_device_lower together with the
related passes pass_oacc_loo
Extend dump output to make understanding why Graphite rejects to
include a loop in a SCoP easier (for GCC developers).
ChangeLog:
* graphite-scop-detection.c (scop_detection::can_represent_loop):
Output reason for failure to dump file.
(scop_detection::harmful_loop_in_regi
From: Sandra Loosemore
The Fortran front end presently linearizes accesses to
multi-dimensional arrays by combining the indices for the various
dimensions into a series of explicit multiplies and adds with
refactoring to allow CSE of invariant parts of the computation.
Unfortunately this represen
ctors" and two
trivial unrelated commits "fa558c2a6664 Fix gimple_debug_cfg
declaration" and "35cdc94463fe Fix branch prediction dump message"
Andrew Stubbs (2):
openacc: Add data optimization pass
openacc: Add runtime alias checking for OpenACC kernels
Frederik Harwath
Hi Richard,
Richard Biener writes:
> On Thu, Nov 12, 2020 at 11:11 AM Frederik Harwath
> wrote:
>>
>> This patch enables the use of Graphite for the analysis of OpenACC
>> "auto" loops. [...]
>> Furthermore, Graphite is extended by functionality t
This patch changes the "kernels" conversion to route loops in OpenACC
"kernels" regions through Graphite. This is done by converting the loops
in "kernels" regions which are not yet known to be "independent" to
"auto" loops as in the current (OG10) "parloops" based "kernels"
handling. Afterwards,
This patch enables the use of Graphite for the analysis of OpenACC
"auto" loops. The goal is to decide if a loop may be parallelized
(i.e. converted to an "independent" loop) or not. Graphite and the
functionality on which it relies (scalar evolution, data references) are
extended to interpret t
ass which converts OpenACC kernels regions to parallel
regions from OG10 (commit 809ea59722263eb6c2d48402e1eed80727134038).
Best regards,
Frederik
Frederik Harwath (2):
[WIP] OpenACC: Add Graphite-based handling of "auto" loops
OpenACC: Add Graphite-based "kernels
Hi Richard,
Richard Biener writes:
> On Tue, Nov 3, 2020 at 4:31 PM Frederik Harwath
> What's on my TODO list (or on the list of things to explore) is to make
> the dump file names/suffixes explicit in passes.def like via
>
> NEXT_PASS (pass_ccp, true /* nonzero_p */,
gistergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
>From 9eb5da60e8822e1f6fa90b32bff6123ed62c146c Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Wed, 4 Nov 2020 14:09:46 +0100
Subject: [PATCH] testsuite: Clean up lto and offload dump files
Dump files produced from an
om 93fb166876a0540416e19c9428316d1370dd1e1b Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Tue, 3 Nov 2020 12:58:37 +0100
Subject: [PATCH] Move pass_oacc_device_lower after pass_graphite
As a first step towards enabling the use of Graphite for optimizing
OpenACC loops, the OpenACC device lo
d) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
>From 7c10ae450b95495dda362cb66770bb78b546592e Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Mon, 20 Jul 2020 11:24:21 +0200
Subject: [PATCH] libgomp, Fortra
Thomas Schwinge writes:
Hi Thomas,
> (CC added, for everything touching gfortran.)
Thanks!
> On 2020-07-07T10:52:08+0200, Frederik Harwath
> wrote:
>> This patch fixes the check for reductions on orphaned gang loops
>
> This is the "Make OpenACC orphan gang reduct
München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
>From 7320635211fff3a773beb0de1914dbfcc317ab37 Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Tue, 7 Jul 2020 10:41:21 +0200
Subject: [PATCH] libgomp, Fortran: Fix OpenACC "gang
Frederik Harwath writes:
ping :-)
> Frederik Harwath writes:
>
> Hi Rainer, hi Mike,
> ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545803.html
>
> Best regards,
> Frederik
>
>> Hi Thomas,
>>
>> Thomas Schwinge writes:
>>
>>&
Frederik Harwath writes:
Hi Rainer, hi Mike,
ping: https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545803.html
Best regards,
Frederik
> Hi Thomas,
>
> Thomas Schwinge writes:
>
>> I can't formally approve testsuite patches, but did a review anyway:
>
> Thanks
Martin Liška writes:
Hi Martin,
> On 5/19/20 11:45 AM, Frederik Harwath wrote:
> Thank you Frederick for the patch.
>
> Looking at what I grepped:
> https://github.com/marxin/gcc-changelog/issues/1#issuecomment-621910248
I get a 404 error when I try to access this URL. The repos
ommit the patch?
Best regards,
Frederik
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
>From 0dc9b201bc1607de36cb9b3604a87cc3646292e3 Mon Sep 17 00:00:00 2001
From: Frederik Har
Hi Thomas,
Thomas Schwinge writes:
> I can't formally approve testsuite patches, but did a review anyway:
Thanks for the review!
> On 2020-05-15T12:31:54+0200, Frederik Harwath
> wrote:
>> The dump
>> scanning procedures are changed to make the test unresolved
&
e than one file (due to an
attempt to call "open" on multiple files) while a failure to
match any file results in an unresolved test.
This commit documents the globbing behavior. The dump
scanning procedures are changed to make the test unresolved
if globbing matches more than o
ot;scan_omp_for".
I have executed "make check" (on x86_64-linux-gnu) to verify that the
change causes no regressions. Ok to push the commit to master?
Best regards,
Frederik
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergeric
Hi Thomas,
Thomas Schwinge writes:
> On 2020-03-25T18:09:25+0100, I wrote:
>> On 2018-02-22T12:23:25+0100, Tom de Vries wrote:
>>> when using cuda 9 nvprof with an openacc executable, the executable hangs.
>
>> What Frederik has discovered today in the hard way... [...]
>> -- the hang was bac
Tobias Burnus writes:
Hi Tobias,
> Fortran patch: https://gcc.gnu.org/pipermail/gcc-patches/current/541774.html
>
> "A declare directive must be in the same scope
> as the declaration of any var that appears in
> the data clauses of the directive."
>
> ("A declare directive is used […] follo
Check that the column information for OpenACC clauses is communicated correctly
to the middle-end, in particular by the Fortran front-end (cf. PR 92793).
2019-12-10 Frederik Harwath
gcc/testsuite/
* gcc.dg/goacc/clause-locations.c: New test.
* gfortran.dg/goacc/clause
ok to include them in trunk?
Best regards,
Frederik
Frederik Harwath (2):
Use clause locations in OpenACC nested reduction warnings
Add tests to verify OpenACC clause locations
gcc/omp-low.c | 2 +-
gcc/testsuite/gcc.dg/goacc/clause-locations.c | 17 +++
1 - 100 of 104 matches
Mail list logo
