Re: [PATCH 15/40] graphite: Extend SCoP detection dump output

Hi Richard, On Tue, 2022-05-17 at 08:21 +, Richard Biener wrote: > On Mon, 16 May 2022, Tobias Burnus wrote: > > > As requested by Richard: Rediffed patch. > > > > Changes: s/.c/.cc/ + some whitespace changes. > > (At least in my email reader, some were lost. I also fixed > > too-long line >

[PATCH, committed][OpenACC] Adapt libgomp acc_get_property.f90 test

Hi, The commit r10-6721-g8d1a1cb1b816381bf60cb1211c93b8eba1fe1472 has changed the name of the type that is used for the return value of the Fortran acc_get_property function without adapting the test acc_get_property.f90. This obvious patch fixes that problem. Committed as r10-6782-g83d45e1d7155a

Re: [PATCH] openmp: ignore nowait if async execution is unsupported [PR93481]

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

[PATCH] openmp: ignore nowait if async execution is unsupported [PR93481]

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

Re: [PATCH] xfail and improve some failing libgomp tests

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

[PATCH] xfail and improve some failing libgomp tests

Hi, the libgomp testsuite contains some test cases (all in /libgomp/testsuite/libgomp.c/) which fail with nvptx offloading because of some long standing issues: * {target-32.c, thread-limit-2.c}: no "usleep" implemented for nvptx. Cf. https://gcc.gnu.org/PR81690 * target-{33,34}.c: no "GOMP_OFFL

Re: Make OpenACC 'acc_get_property' with 'acc_device_current' work (was: [PATCH] Add OpenACC 2.6 `acc_get_property' support)

Hi Thomas, On 30.01.20 16:54, Thomas Schwinge wrote: > > [...] the 'acc_device_current' interface should work already now. > > [...] Please review > the attached (Tobias the Fortran test cases, please), and test with AMD > GCN offloading. If approving this patch, please respond with I have tes

Re: [PATCH] Add OpenACC acc_get_property support for AMD GCN

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

Re: [PATCH] Add OpenACC acc_get_property support for AMD GCN

Hi Thomas, On 29.01.20 18:44, Thomas Schwinge wrote: >> + size_t len = sizeof hsa_context.driver_version_s; >> + int printed = snprintf (hsa_context.driver_version_s, len, >> + "HSA Runtime %hu.%hu", (unsigned short int)major, >> + (unsigned short int)m

[PATCH][OpenACC] Add acc_device_radeon to name_of_acc_device_t function

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 2

Re: [PATCH] Add OpenACC acc_get_property support for AMD GCN

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

Re: [PATCH] Add OpenACC acc_get_property support for AMD GCN

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

[PATCH] Add OpenACC acc_get_property support for AMD GCN

Hi, this patch adds full support for the OpenACC 2.6 acc_get_property and acc_get_property_string functions to the libgomp GCN plugin. This replaces the existing stub in libgomp/plugin-gcn.c. Andrew: The value returned for acc_property_memory ("size of device memory in bytes" according to the spe

Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support

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

Re: [PATCH][amdgcn] Add runtime ISA check for amdgcn offloading

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

Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support

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

[PATCH][amdgcn] Add runtime ISA check for amdgcn offloading

Hi, this patch implements a runtime ISA check for amdgcn offloading. The check verifies that the ISA of the GPU to which we try to offload matches the ISA for which the code to be offloaded has been compiled. If it detects a mismatch, it emits an error message which contains a hint at the correct

*ping* - Re: [Patch] Rework OpenACC nested reduction clause consistency checking (was: Re: [PATCH][committed] Warn about inconsistent OpenACC nested reduction clauses)

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

Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support

Hi Thomas, >> Is it ok to commit the patch to trunk? > > OK, thanks. And then some follow-up/clean-up next year, also including > some of the open questions that I've snipped off here. Right, thanks for the review! I have committed the patch as r279710 with a minor change: I have disabled the n

Re: [PATCH] Add OpenACC 2.6 `acc_get_property' support

Hi Thomas, thanks for the review! I have attached a revised patch. > > There is no AMD GCN support yet. This will be added later on. > > ACK, just to note that there now is a 'libgomp/plugin/plugin-gcn.c' that > at least needs to get a stub implementation (can mostly copy from > 'libgomp/plugin/pl

[PATCH, committed] Fix PR92901: Change test expectation for C++ in OpenACC test clause-locations.c

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 --

Re: [PATCH 0/2] Add tests to verify OpenACC clause locations

Hi Thomas, On 10.12.19 15:44, Thomas Schwinge wrote: > Thanks, yes, with my following remarks considered, and acted on per your > preference. To record the review effort, please include "Reviewed-by: > Thomas Schwinge " in the commit log, see > . Committed

Re: [PATCH 0/2] Add tests to verify OpenACC clause locations

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 one > patch: bug fix plus test cases

[PATCH] Fix column information for omp_clauses in Fortran code

Hi, Tobias has recently fixed a problem with the column information in gfortran locations ("PR 92793 - fix column used for error diagnostic"). Diagnostic messages for OpenMP/OpenACC clauses do not contain the right column information yet. The reason is that the location information of the first

[PATCH][AMDGCN] Skip test gcc/testsuite/gcc.dg/asm-4.c

Hi, the inline assembly "p" modifier ("An operand that is a valid memory address is allowed", cf. https://gcc.gnu.org/onlinedocs/gcc/Simple-Constraints.html#Simple-Constraints) is not supported on AMD GCN. This causes an ICE during the compilation of gcc.dg/asm-4.c. We should skip the test for t

Re: [Patch, Fortran] PR 92793 - fix column used for error diagnostic

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 (fortran/error.c), t

Re: [PATCH 2/4] Validate acc_device_t uses

Hi Thomas, On 03.12.19 13:14, Thomas Schwinge wrote: > You once had this patch separate, but then merged into the upstream > submission of 'acc_get_property'; let's please keep this separate. > > With changes as indicated below, please commit this to trunk [...] Ok, I have committed the patch as

[Patch] Rework OpenACC nested reduction clause consistency checking (was: Re: [PATCH][committed] Warn about inconsistent OpenACC nested reduction clauses)

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: [PATCH] Fix ICE in re-simplification of VEC_COND_EXPR

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

Re: [PATCH] Fix ICE in re-simplification of VEC_COND_EXPR (was: Re: [PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR)

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_conditional_op): Use generic_

[PATCH] Fix ICE in re-simplification of VEC_COND_EXPR (was: Re: [PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR)

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

Re: [PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR

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

[PATCH][amdgcn] Fix ICE in re-simplification of VEC_COND_EXPR

Hi, currently, on trunk, the tests gcc.dg/vect/vect-cond-reduc-1.c and gcc.dg/pr68286.c fail when compiling for amdgcn-unknown-amdhsa. The reason seems to lie in the interaction of the changes that have been introduced by revision r276659 ("Allow COND_EXPR and VEC_COND_EXPR condtions to trap" by

Re: [PATCH 5/7] Remove last leftover usage of params* files.

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

Re: [PATCH][committed] Warn about inconsistent OpenACC nested reduction clauses

Hi Jakub, On 06.11.19 14:00, Jakub Jelinek wrote: > On Wed, Nov 06, 2019 at 01:41:47PM +0100, frede...@codesourcery.com wrote: >> --- a/gcc/omp-low.c >> +++ b/gcc/omp-low.c >> @@ -128,6 +128,12 @@ struct omp_context >> [...] >> + /* A tree_list of the reduction clauses in this context. */ >> +

Re: [PATCH] Report errors on inconsistent OpenACC nested reduction clauses

Hi Thomas, On 05.11.19 15:22, Thomas Schwinge wrote: > For your convenience, I'm attaching an incremental patch, to be merged > into yours.> [...]> With that addressed, OK for trunk. Thank you. I have merged the patches and committed. > A few more comments to address separately, later on. I wi

Re: Add OpenACC 2.6 `acc_get_property' support

Hi Thomas, > On 07.10.19 20:41, Thomas Schwinge wrote: > > On 2018-12-03T16:51:14+, "Maciej W. Rozycki" > > wrote: > > Add generic support for the OpenACC 2.6 `acc_get_property' and > > `acc_get_property_string' routines [...] > > ..., which allow for user code to query the implementation fo

Re: [PATCH] Report errors on inconsistent OpenACC nested reduction clauses

On 24.10.19 16:31, Thomas Schwinge wrote: Hi, I have attached a revised patch. [...] I was wondering if the way in which the patch avoids issuing errors about operator switches more than once by modifying the clauses (cf. the corresponding comment in omp-low.c) could lead to problems [...] "

[PATCH] Report errors on inconsistent OpenACC nested reduction, clauses

Hi, OpenACC requires that, if a variable is used in reduction clauses on two nested loops, then there must be reduction clauses for that variable on all loops that are nested in between the two loops and all these reduction clauses must use the same operator; this has been first clarified by Op

Add myself to MAINTAINERS files

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 + + *

Re: [PATCH] libgomp_g.h: Include stdint.h instead of gstdint.h

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 libgomp less portable. [...] >