From: frederik
OpenACC (cf. OpenACC 2.7, section 2.9.11. "reduction clause";
this was first clarified by OpenACC 2.6) requires that, if a
variable is used in reduction clauses on two nested loops, then
there must be reduction clauses for that variable on
Hi,
the following patch has been reviewed and committed.
Frederik
--- 8< --
The `serial' construct (cf. section 2.5.3 of the OpenACC 2.6 standard)
is equivalent to a `parallel' construct with clauses
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,
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
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
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
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:
*
titled "openacc: Use Graphite
for dependence analysis in \"kernels\" regions" whose commit message
also contains further explanations.
Best regards,
Frederik
PS: The commit series also includes a backport from master
"00b98b6cac25 Add dg-final option-based target sele
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
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
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
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 ...
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-
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_
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
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
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
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:
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
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
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"
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
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
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 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 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
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
I also fixed
> > too-long line
> > issues.)
> >
> > In addition, FOR_EACH_LOOP was replaced by 'for (auto loop : ...'
> > (macro was removed late in GCC 12 development ? r12-2605-
> > ge41ba804ba5f5c)
> >
> > Otherwise, it should be identi
- }
-
#pragma acc parallel
{
#pragma acc loop reduction(+:c)
That one stays in, but gets a 'dg-warning'.
What warning would you expect to see here? I do not get any warnings.
Best regards,
Frederik
>From 22f45d4c2c11febce171272f9289c487aed4f9d7 Mon Sep 17 00:00:00
+int main ()
> > +{
> > + const char *s;
> > + size_t v;
> > + int r;
> > +
> > + /* Verify that the vendor is a proper non-empty string. */
> > + s = acc_get_property_string (0, acc_device_default, acc_property_vendor);
> > + r = !s || !strlen (s);
> > + if (s)
> > +printf ("OpenACC vendor: %s\n", s);
>
> Should we check the actual string returned, as defined by OpenACC/our
> implementation, as applicable? Use '#if defined ACC_DEVICE_TYPE_[...]'.
> (See 'libgomp/testsuite/libgomp.oacc-c-c++-common/avoid-offloading-2.c',
> for example.)
Yes.
> Isn't this the "Device vendor" instead of the "OpenACC vendor"? Similar
> for all other 'printf's?
Yes.
> These tests only use 'acc_device_default', should they also check other
> valid as well as invalid values?
That would be better.
Frederik
rately, later on.
I will look into your remaining questions.
Best regards,
Frederik
Hi,
this patch implements the OpenACC 2.6 "serial" construct.
It has been tested by running the testsuite with nvptx-none
offloading on x86_64-pc-linux-gnu.
Best regards,
Frederik
8< ---
The `serial' construct (cf. section 2.5.3
or the local ones, and put into both
> the clauses, so you can compare reduction code etc.
Sounds like a good idea. I am going to try that.
However, I have not seen the suboptimal data structure choices
of the original patch as a problem, since the case of million reduction clauses
has not occurred to me.
Thank you for your feedback!
Best regards,
Frederik
Hi Martin,
On 06.11.19 13:40, Martin Liska wrote:
> (finalize_options_struct): Remove.
This patch has been committed by now, but it seems that a single use of
finalize_options_struct has been overlooked
in gcc/tree-streamer-in.c.
Best regards,
Frederik
at run on the device lowered
function if necessary.
Ok to include the patch in master?
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
>Fr
ot;exe" should be included here. I have removed it
and I did not notice any files matching the resultig pattern being left
back by "make check-gcc".
Best regards,
Frederik
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Re
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 */,
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
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
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,
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
tecture of the GPU.
It seems difficult to implement an automated test that triggers an ISA mismatch.
I have tested manually (for different combinations of the compilation flags
and offloading GPU ISAs) that the runtime ISA check produces the expected error
messages.
Is it ok to commit this patch to the
Hi Thomas,
I have attached a patch containing the changes that you suggested.
On 16.01.20 17:00, Thomas Schwinge wrote:
> On 2019-12-20T17:46:57+0100, "Harwath, Frederik"
> wrote:
>> --- /dev/null
>> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/acc_get_pr
Hi Andrew,
Thanks for the review! I have attached a revised patch containing the changes
that you suggested.
On 20.01.20 11:00, Andrew Stubbs wrote:
> On 20/01/2020 06:57, Harwath, Frederik wrote:
>> Is it ok to commit this patch to the master branch?
>
> I can't see an
Hi Thomas,
On 23.01.20 15:32, Thomas Schwinge wrote:
> On 2020-01-20T15:01:01+0100, "Harwath, Frederik"
> wrote:
>> On 16.01.20 17:00, Thomas Schwinge wrote:
>>> On 2019-12-20T17:46:57+0100, "Harwath, Frederik"
>>> wrote:
>> Ok to
Best regards,
Frederik
From 6f1855281c38993a088f9b4af020a786f8e05fe9 Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Tue, 28 Jan 2020 08:01:00 +0100
Subject: [PATCH] Add OpenACC acc_get_property support for AMD GCN
Add full support for the OpenACC 2.6 acc_get_property and
acc_get_property_s
Hi Andrew,
On 28.01.20 16:42, Andrew Stubbs wrote:
> On 28/01/2020 14:55, Harwath, Frederik wrote:
>
> If we're going to use a fixed-size buffer then we should use snprintf and
> emit GCN_WARNING if the return value is greater than
> "sizeof(driver_version_s)", ev
Hi Andrew,
On 29.01.20 11:38, Andrew Stubbs wrote:
> On 29/01/2020 09:52, Harwath, Frederik wrote:
>
> Patch 1 is OK with the formatting fixed.
> Patch 2 is OK.
>
> Thanks very much,
>
Committed as 2e5ea57959183bd5bd0356739bb5167417401a31 and
87c3fcfa6bbb5c372d4e275276d
Hi,
we should handle acc_device_radeon in the name_of_acc_device_t function
which is used in libgomp/oacc-init.c to display the name of devices
in several error messages.
Ok to commit this patch to master?
Best regards,
Frederik
From 6aacba3e8123ce5e0961857802fd7d8a103aa96b Mon Sep 17 00:00:00
ourse pre-existing, but) this looks like a dangerous API,
> given that 'hsa_agent_get_info_fn' doesn't know 'sizeof agent->name' (or
> 'sizeof buf' before)...
The API documentation
(cf.
https://rocm-documentation.readthedocs.io/en/latest/ROCm_API_References/ROCr-API.html)
states that "the type of this attribute is a NUL-terminated char[64]".
But, right, should this ever change, we might not notice it.
Best regards,
Frederik
Hi Thomas,
On 30.01.20 17:08, Thomas Schwinge wrote:
> I understand correctly that the only reason for:
>
> On 2020-01-29T10:52:57+0100, "Harwath, Frederik"
> wrote:
>> * testsuite/libgomp.oacc-c-c++-common/acc_get_property-aux.c
>> (expect_devic
a variable
(for instance, "bool allowed_device_type = acc_device_current
|| known_device_type(d);") would also provide a place for your comment.
You could also extract a function to avoid duplicating the explanation
in acc_get_property_string.
The patch looks good to me.
Reviewed-by: Frederik Harwath
Best regards,
Frederik
s also fail on amdgcn.
Since - in contrast to nvptx - it seems that the cause of this failure
has not yet been investigated and discussed, I have not added an xfail
for amdgcn to this test.
All testing has been done with a x86_64-linux-gnu host and target.
Ok to commit this patch?
Best regards,
Fr
Hi Jakub,
On 07.02.20 16:29, Jakub Jelinek wrote:
> On Fri, Feb 07, 2020 at 09:56:38AM +0100, Harwath, Frederik wrote:
>> * {target-32.c, thread-limit-2.c}:
>> no "usleep" implemented for nvptx. Cf. https://gcc.gnu.org/PR81690
>
> Please don't, I want to
Hi Jakub,
On 10.02.20 08:49, Harwath, Frederik wrote:
>> There has been even in some PR a suggestion that instead of failing
>> in nvptx async_run we should just ignore the nowait clause if the plugin
>> doesn't implement it properly.
>
> This must be https://gcc.g
Hi Jakub,
On 13.02.20 09:30, Jakub Jelinek wrote:
> On Thu, Feb 13, 2020 at 09:04:36AM +0100, Harwath, Frederik wrote:
>> --- a/libgomp/target.c
>> +++ b/libgomp/target.c
>> @@ -2022,6 +2022,16 @@ GOMP_target (int device, void (*fn) (void *), const
>> void *un
Hi Tobias,
On 04.12.19 14:37, Tobias Burnus wrote:
> As reported internally by Frederik, gfortran currently passes LOCATION_COLUMN
> == 0 to the middle end. The reason for that is how parsing works – gfortran
> reads the input line by line.
>
> For internal error diagnostic (
ld skip the test for the amdgcn-*-* target.
Can I merge the patch below into trunk?
Best regards,
Frederik
2019-12-05 Frederik Harwath
gcc/testsuite/
* gcc.dg/asm-4.c: Skip on target amdgcn-*-*.
Index: gcc/test
clauses in warnings instead of the location of the
loop to which the clause belongs.
I can add a regression test based on this later on after adapting the code in
omp-low.c.
Is it ok to include the patch in trunk?
Best regards,
Frederik
On 04.12.19 14:37, Tobias Burnus wrote:
> As reported
Since the Fortran front-end now sets the clause locations correctly, we can
emit warnings with more precise locations if we encounter conflicting
operations for a variable in reduction clauses.
2019-12-10 Frederik Harwath
gcc/
* omp-low.c (scan_omp_for): Use clause location in warning
Hi,
On 09.12.19 16:58, Harwath, Frederik wrote:
> Tobias has recently fixed a problem with the column information in gfortran
> locations
> [...]
> I have tested the patch manually by adapting the validity check for nested
> OpenACC reductions (see omp-low.c)
> to inclu
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
Hi Thomas,
On 10.12.19 15:44, Thomas Schwinge wrote:
>> Frederik Harwath (2):
>> Use clause locations in OpenACC nested reduction warnings
>> Add tests to verify OpenACC clause locations
>
> I won't insist, but suggest (common practice) to merge that into o
/Reviewed-by>.
Committed as r279168 and r279169.
Frederik
Hi,
I have committed the attached trivial patch to trunk as r279215. The columns of
the clause locations are reported differently
by the C and C++ front-end and hence we need different test expectations for
both languages.
Best regards,
Frederik
orrect?
Yes, he has done that internally.
> | Before Frederik starts working on integrating this into GCC trunk, do you
> | (Jakub) agree with the libgomp plugin interface changes as implemented by
> | Maciej? For example, top-level 'GOMP_OFFLOAD_get_property' function in
>
I have disabled the new acc_get_property.{c,f90} tests for
the amdgcn offload target for now.
Best regards,
Frederik
PING
Hi Jakub,
I have attached a version of the patch that has been rebased on the current
trunk.
Frederik
On 03.12.19 12:16, Harwath, Frederik wrote:
> On 08.11.19 07:41, Harwath, Frederik wrote:
>> On 06.11.19 14:00, Jakub Jelinek wrote:
>> [...]
>>> I'm not su
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
different xnack settings) that I have and it passes
most libgomp offloading tests.
Although those APUs are very constrainted compared to dGPUs, I think
they might be interesting for learning, experimentation, and testing.
Can I commit the patch to the master branch?
Best regards,
Frederik
From
-g83d45e1d7155a5a600d8a4aa01aca00d3c6c2d3a.
Best regards,
Frederik
From 83d45e1d7155a5a600d8a4aa01aca00d3c6c2d3a Mon Sep 17 00:00:00 2001
From: Frederik Harwath
Date: Fri, 21 Feb 2020 15:26:02 +0100
Subject: [PATCH] Adapt libgomp acc_get_property.f90 test
The commit r10-6721
t; new file mode 100644
> index 000..8515c4ff875
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/declare-pr94120.C
> @@ -0,0 +1,30 @@
> +/* { dg-do compile } */
> +
> +/* PR middle-end/94120 */
> +
> +int b[8];
> +#pragma acc declare create (b)
Looks good to me.
Frederik
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
subtle reason for
forbidding the gang reductions on kernels loops. As expect, there seems
to be no such reason, i.e. I observed no regressions with the patch.
Can I include the patch in OG10?
Best regards,
Frederik
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634
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
onstruct testing, for a different reason,
> so I'll include it there.)
I forgot to remove "libgomp" from the commit message, sorry, but
I have included the test cases for the "serial construct".
Best regards,
Frederik
-
Mentor Graphics (Deutschlan
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
"outer_reduction_clauses" field and the "local_reduction_clauses" field
from "new_omp_context" completely. (The fields are still zero intialized
by the allocation of the struct which uses XCNEW.) That way the whole
logic regarding the fields is now contained in &qu
es fail to compile when running the tests
with the installed GCC.
I have tested the patch with "make check" on x86_64 GNU/Linux.
Best regards,
Frederik
libgomp/ChangeLog:
2019-09-25 Kwok Cheung Yeung
* libgomp_g.h: Include stdint.h instead of gstdint.h.
diff --git a/l
Hi Jakub,
Am 30.09.2019 um 09:25 schrieb Jakub Jelinek:
> On Mon, Sep 30, 2019 at 12:03:00AM -0700, Frederik Harwath wrote:
>> The patch changes libgomp/libgomp_g.h to include stdint.h instead of the
>> internal gstdint.h. [...]
>
> That looks wrong, will make
2019-10-01 Frederik Harwath
* MAINTAINERS: Add myself to Write After Approval
Index: ChangeLog
===
--- ChangeLog (revision 276390)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2019-10-01 Frederik Harwath
e for such
checks. Should this be a part of "pass_lower_omp" (as in the patch) or should
it run earlier
like, for instance, "pass_diagnose_omp_blocks".
Can the patch be included in trunk?
Frederik
>From 99796969c1bf91048c6383dfb1b8576bdd9efd7d Mon Sep 17 00:00:00 2001
ble-languages=C only build, but this covers lots of uses
of the affected test procedures) and observed no regressions.
Ok to commit this to master?
Best regards,
Frederik
-
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HR
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
&
eady knows about "Co-Authored-By" lines and I have extended it to
handle the "Reviewed-{by,on}" lines in a similar way. The information
from those lines is not processed further since the review information
apparantly does not get included in the ChangeLogs.
Ok to c
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
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
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:
>>
>>&
Hi,
this patch implements OpenACC 2.6 "acc_get_property" and related functions.
I have tested the patch on x86_64-linux-gnu with nvptx-none offloading.
There is no AMD GCN support yet. This will be added later on.
Can this be committed to trunk?
Best regards,
Frederik
---
; which I have executed for targets
amdgcn-unknown-amdhsa
and x86_64-pc-linux-gnu.
Best regards,
Frederik
2019-11-28 Frederik Harwath
gcc/
* gimple-match-head.c (maybe_resimplify_conditional_op): use
generic_expr_could_trap_p to check if the condition of COND_E
Hi Richard,
On 29.11.19 13:37, Richard Biener wrote:
> On Fri, Nov 29, 2019 at 1:24 PM Harwath, Frederik
> wrote:
> [...]
>> It seems that this rule is not invoked when compiling for x86_64 where the
>> generated code for vect-cond-reduc-1.c does not contain anything tha
Hi,
On 29.11.19 13:51, Harwath, Frederik wrote:
>> condition for the inner vec_cond. Your fix looks reasonable but is
>> very badly formatted. Can you instead do
I hope the formatting looks better now. I have also removed the [amdgcn] from
the subject line since
the fact that t
Hi Jakub,
On 29.11.19 14:41, Jakub Jelinek wrote:
> s/use/Use/
>
> [...]
>
> s/. /. /
Right, thanks. Does that look ok for inclusion in trunk now?
Best regards,
Frederik
2019-11-29 Frederik Harwath
gcc/
* gimple-match-head.c (maybe_resimplify_condi
On 29.11.19 15:46, Richard Sandiford wrote:
> Thanks for doing this, looks good to me FWIW. I was seeing the same
> failure for SVE but hadn't found time to look at it.
Thank you all for the review. Committed as r278853.
Frederik
Hi Jakub,
On 08.11.19 07:41, Harwath, Frederik wrote:
> On 06.11.19 14:00, Jakub Jelinek wrote:
> [...]
>> I'm not sure it is a good idea to use a TREE_LIST in this case, vec would be
>> more natural, wouldn't it.
>
> Yes.
>
> [...]
>> If gimplifie
re, so OK to change as
> you did?
Right, I do not see any reasons why it should accept ACC_device_hwm and
the change did not cause any regressions.
Best regards,
Frederik
r278937 | frederik | 2019-12-03 15:38:54 +01
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
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
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
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
1 - 100 of 147 matches
Mail list logo
