[Patch] Fortran/OpenMP: Fix declare_variant's 'adjust_args' mishandling with return by reference [PR118321]

For declare_variant's 'adjust_args', the arguments for need_device_ptr are referenced by argument number. This patch fixes that calculation if hidden arguments due to return-by-reference calling exist. Note: It only fixes the Fortran issue; the C++ issue still needs to be fixed. Build + regteste

[Patch] Fortran: Create fresh ts.u.cl for result in gfc_get_symbol_for_expr [PR118441]

As shown in the PR, updating the function declaration for _gfortran_pack_char could leak into the character typespec back-end declaration to the the caller by setting the backend declaration of the caller. The problem is that that function returns a character string and in trans-intrinsic.cc, we

Re: [PATCH] Accept commas between clauses in OpenMP declare variant

Hi PA, Paul-Antoine Arras wrote: I am not sure I am getting that part. Is this what you are suggesting? Yes, something like that, but not quite, as you found out. I think we need something like the following (untested): diff --git gcc/fortran/openmp.cc gcc/fortran/openmp.cc index 9d28dc

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

Hi, On 9/25/24 3:18 AM, Andre Vehreschild wrote: @@ -3089,7 +3099,15 @@ typedef struct gfc_code   gfc_inquire *inquire;   gfc_wait *wait;   gfc_dt *dt; -    gfc_forall_iterator *forall_iterator; + +    struct +    { +  gfc_forall_iterator *forall_iterator; +  gfc_expr_list *

Re: [Patch] Fortran: Fix location_t in gfc_get_extern_function_decl; support 'omp dispatch interop'

Hi Thomas, Thomas Koenig wrote: Comments, remarks, suggestions? I assume you regression-tested (you didn't say). Yes, it was build with a bootstrapping configuration (with a non-offloading compiler, but it shouldn't matter here) on x86_64-gnu-linux and I did run "make check-fortran" in the m

[Patch] Fortran: Fix location_t in gfc_get_extern_function_decl; support 'omp dispatch interop'

The first change is a simple, generic Fortran change. Without it, external declarations have odd locations (namely their input_location): gcc/testsuite/gfortran.dg/gomp/dispatch-11.f90:67:46: 67 | !$omp dispatch interop(obj2, obj1) device(3) |

[Patch] OpenMP: Enable has_device_addr clause for 'dispatch' in Fortran

Support the 'has_device_addr' clause with OpenMP's 'dispatch' directive. The testcase is even more questionable as the C/C++ testcase (looking at it globally/semantically), but it tests (locally) what it is supposed to test: namely, 'has_device_addr' does not fulfill the 'is_device_ptr' property

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

Hi PA, Paul-Antoine Arras wrote: Folded everything in one patch. […] Updated ChangeLog. […] Thanks. Rebased and amended accordingly. I believe I did the right thing but please have a quick look to be sure. ... Otherwise, LGTM. Thanks! LGTM :-) For libgomp.fortran/dispatch-3.f90, see just

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

Hi PA, Paul-Antoine Arras wrote: On 27/12/2024 19:52, Paul-Antoine Arras wrote: Running adjust-args-10.f90 manually exhibited a bug that no other testcase triggered. So I fixed the bug; then moved adjust-args-10.f90 to the libgomp testsuite, renamed it to dispatch-3.f90 and made it dg-run. I

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

Hi PA, (next try, for some reasons, my original email disappeared.) Paul-Antoine Arras wrote: Replying to your last two messages here and attaching revised patches. Regarding the C++ and ME patches: ==> 0003-C-fix.patch <== Subject: [PATCH 3/4] C++ fix ==> 0004-ME-fixes.patch <== Subject:

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

Hi all, hello PA, Tobias Burnus wrote: Paul-Antoine Arras wrote: See the revised patch attached and my comments below. I have not looked in depth at the patch, but managed to write C-ism code, which caused a segfault (due to a missing "call"), Additional comments: Can you

Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

Hi PA, Paul-Antoine Arras wrote: See the revised patch attached and my comments below. First, for Fortran patches, please also CC fortran@ besides gcc-patches@. The original patch email can be found at: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671763.html I have not looked in

[Patch] OpenMP: 'allocate' directive - fixes for 'alignof' and [[omp::decl]]

In C, [[omp::decl]] wasn't supported and when discussing 'alignof' with Jakub, he pointed out that there are corner cases (see commit log for one), which imply that it is better that 'omp allocate align(…) doesn't affect 'alignof'. The patch now removes the alignment handling from the FE (C and Fo

Re: [PATCH] Fortran: fix crash with bounds check writing array section [PR117791]

H Harald, hi Paul, Harald Anlauf wrote: Pushed as r15-5766 . This caused a build fail; see also: https://gcc.gnu.org/PR117843 It looks as if a 'default: break;' is missing. …/gcc/fortran/trans-io.cc: In function 'tree_node* gfc_trans_transfer(gfc_code*)': …/gcc/fortran/trans-io.cc:2662:24:

[Patch][v2] OpenMP: 'interop' construct - add C parser support, improve Fortran pasing

_GOMP_UINTPTR_T_ENUM macro definitions. Otherwise it is unchanged. Tobias Tobias Burnus wrote: Background: omp interop device(1) init(prefer_type("cuda"), targetsync: obj) depend(inout: x) nowait … omp interop destroy(obj) initializes the omp_interop_t / integer(omp_interop

[Patch] OpenMP: 'interop' construct - add C parser support, improve Fortran pasing

Background: omp interop device(1) init(prefer_type("cuda"), targetsync: obj) depend(inout: x) nowait … omp interop destroy(obj) initializes the omp_interop_t / integer(omp_interop_kind) variable for device '1' and (thanks to 'targetsync') creates a stream object. 'obj' can then be used

[committed] Fortran: Minor follow-up cleanup to error.cc

Committed attached patch as r15-4565-g0ecc45a88d7722. It removes 'terminal_width', an unused leftover before switching to the common diagnostic, which I missed when doing the last cleanup. Best regards, Tobias commit 0ecc45a88d772268a3bd83af02759857da0826d4 Author: Tobias Burnus D

Re: [PATCH] Implement Fortran diagnostic buffering for non-textual formats [PR105916]

David Malcolm wrote: In order to handle various awkward parsing issues, the Fortran frontend implements buffering of diagnostics, so that diagnostics reported to global_dc can be either: (a) immediately issued, or (b) speculatively reported to global_dc, and stored in a buffer, to either be issue

Re: [Patch, fortran] PR116733: Generic processing of assumed rank objects (f202y)

Regarding 202y: I think it is in general useful to have an implementation of features before the standard is released, also to find issues before the standard is released. The downside I currently see is that the none of the features is really ready (in the sense that there are explicit edits).

Fortran: Add range-based diagnostic

This patch was motivated by David's talk at Cauldron – and by getting rather bad locations for some diagnostics, where I wanted to use the column number to ensure that all items are found. The main problem was a missing gobbling of spaces, but still ranges are way nicer. As gfortran uses the comm

Re: [Patch] Fortran: Fix translatability of diagnostic strings

*Patch ping* Tobias Burnus wrote: I noticed that several diagnostic strings were not tagged as translatable. I fixed them by adding _ or G_ as prefix ( →gcc/ABOUT-GCC-NLS) and moved a single-use string to the message to make it more readable. One error message did not quit fit the pattern

[committed] Add libgomp.oacc-fortran/acc_on_device-1-4.f (was: Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device: Harmonize 'libgomp.oacc-fortran/acc_on_device-1-*'

see attached. by re-adding a testcase which actually tests the builtin. Committed as r15-4388-gee4fdda70f1080. Tobias commit ee4fdda70f1080bba5e49cadebc44333e19edeb4 Author: Tobias Burnus Date: Wed Oct 16 16:15:40 2024 +0200 Add libgomp.oacc-fortran/acc_on_device-1-4.f Kind of u

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device

Now pushed as r15-4298-g3269a722b7a036. Thanks to Bernhard for some proof reading! Tobias Tobias Burnus wrote: Anyone feeling like reviewing this patch? (Mainly the Fortran side?!?) — Or should I declare it as OpenMP/(OpenACC) patch and just commit it? → https://gcc.gnu.org/pipermail/gcc

[Patch] Fortran: Fix translatability of diagnostic strings

I noticed that several diagnostic strings were not tagged as translatable. I fixed them by adding _ or G_ as prefix ( →gcc/ABOUT-GCC-NLS) and moved a single-use string to the message to make it more readable. One error message did not quit fit the pattern, hence, I modified it slightly, and a fe

Re: [Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device (was: [Patch]

Anyone feeling like reviewing this patch? (Mainly the Fortran side?!?) — Or should I declare it as OpenMP/(OpenACC) patch and just commit it? → https://gcc.gnu.org/pipermail/gcc-patches/2024-October/664985.html Tobias Tobias Burnus write: I forgot to update the subject line. To make it easier

Re: [Patch] Fortran/OpenMP: Warn when mapping polymorphic variables

t for the full log):     * openmp.cc (resolve_omp_clauses): Diagnose polymorphic mapping.     * trans-openmp.cc (gfc_omp_finish_clause): Warn when     polymorphic variable is implicitly mapped. Tobias Tobias Burnus wrote: GCC does not really handle mapping of polymo

[Patch] Fortran: Unify gfc_get_location handling; fix expr->ts bug

This unifies the two locus to location_t conversion functions, preparing for some changes I want to do later. In principle, I had the patch this morning; however, the assert is now exercised more often than before - and it triggered rather unexpected when running the testsuite. Turned out th

[Patch] Fortran: Dead-function removal in error.cc (shrinking by 40%)

I found always error.cc rather confusing but I just realized that we can reduce number of lines in that file by 40% - and remove a lot of (apparent) complexity. The removed code is from the old days, when gfortran handled a lot of diagnostic itself, also because it wanted to show lines with caret

[Patch] Fortran/OpenMP: Warn when mapping polymorphic variables

GCC does not really handle mapping of polymorphic variables - and OpenMP 6 will also make it implementation defined. (While explicitly permitting it with data-sharing clauses.) This matches essentially what is in GCC, except that 'private' (and other privatizations) are not properly handled.

[Patch] Fortran: Use OpenACC's acc_on_device builtin, fix OpenMP' __builtin_is_initial_device (was: [Patch] (was: [Patch] Fortran/OpenMP: Fix __builtin_omp_is_initial_device))

I forgot to update the subject line. To make it easier to find (patch archeology), now with proper subject line … Tobias Burnus wrote: Sometimes waiting a bit leads to better code … Tobias Burnus wrote: ... [I guess, we eventually want to add support for more builtins. For instance

[Patch] (was: [Patch] Fortran/OpenMP: Fix __builtin_omp_is_initial_device)

Sometimes waiting a bit leads to better code … Tobias Burnus wrote: ... [I guess, we eventually want to add support for more builtins. For instance, acc_on_device would be a candidate, but I could imagine some additional builtins.] I have now implemented acc_on_device and I think the new

[Patch] Fortran/OpenMP: Fix __builtin_omp_is_initial_device

Patches gfc_conv_procedure_call (+ called functions). Found via OpenMP_VV which uses rather pointlessly 'if (omp_is_initial_device() .eqv. .true.)' – instead of using 'if (omp_…())'. This failed with an ICE as the middle end did not like 'if ( == )' comparisons. The initial idea was to crea

[committed] Move gfortran.dg/gomp/allocate-static.f90 to libgomp.fortran/ (was: [r15-4104 Regression] FAIL: gfortran.dg/gomp/allocate-static.f90 -Os (test for excess errors) on Linux/x86_64)

Committed as r15-4127-gb95ad25f9c9376 Hi Thomas, Thomas Schwinge wrote: On 2024-10-07T17:07:05+0200, Tobias Burnus wrote: If anyone can reproduce this, I would be interested in the excess errors. gfortran: fatal error: cannot read spec file 'libgomp.spec': No such file or

Re: [Patch] OpenMP: Allocate directive for static vars, clean up

Hi Andre, first, thanks a lot for all your proof reading of patches! That's indeed helpful and reviewing (with offical LGTM stamp or as bystander) is a problem, you help to reduce it! :-) Andre Vehreschild wrote: @@ -821,6 +821,23 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) + if (s

Re: [Patch] OpenMP: Allocate directive for static vars, clean up

Now committed as r15-4104-ga8caeaacf499d5. With a wording improvement in the commit log and avoiding an XPASS for C++ by excluding c++98 from the xfail in dg-bogus... xfail. Tobias Tobias Burnus wrote: 'omp allocate' permits to use a different (specified) allocator and alignmen

[Patch] OpenMP: Allocate directive for static vars, clean up

'omp allocate' permits to use a different (specified) allocator and alignment for both stack/automatic and static/saved variables; the latter takes only predefined allocators. Currently, only C and Fortran are support for stack/automatic variables; static variables are rejected before the attached

Re: [Patch] OpenMP: Update OMP_REQUIRES_TARGET_USED for declare_target + interop

Hi now committed the following as r15-3856-gfcff9c3dad4f35 with two testcase additions (and improved changelog wording). Tobias Burnus wrote: OpenMP mandates that when certain clauses are used with 'omp requires' that in all compilation units this requires clause appears. Tho

[Patch] OpenMP: Update OMP_REQUIRES_TARGET_USED for declare_target + interop

OpenMP mandates that when certain clauses are used with 'omp requires' that in all compilation units this requires clause appears. Those clauses influence the offloading behavior (+ potentially codegen); hence, the must requires must match for those claues when device code is involved. That's

Re: [Patch] OpenMP: Add support for 'self_maps' to the 'require' directive

But no must. Ok for mainline. Thanks for the patch. - Andre On Sat, 21 Sep 2024 23:37:33 +0200 Tobias Burnus wrote: Add support of the 'self_maps' clause in 'omp requires', an OpenMP 6 feature but added here mostly as part of the on-going improvement of the unified-shared m

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

Hi all, I have now downloaded the file at https://gcc.gnu.org/pipermail/gcc-patches/2024-September/663534.html (by copying it from the browser, not the source code to avoid '> This file had had to fix spurious line breaks like:  @@ -5171,7 +5171,7 @@ index_interchange (gfc_code **c, int *wal

Re: OpenMP: Fix omp_get_device_from_uid, minor cleanup

Now committed as r15-3799-gcdb9aa0f623ec7 / https://gcc.gnu.org/r15-3799-gcdb9aa0f623ec7 Tobias Am 21.09.24 um 01:33 schrieb Tobias Burnus: Hi Thomas, hello all, the attached follow-up patch does: * It fixes an issue (thinko) related to Fortran and \0 terminated,   which fails for at least

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

Hi Andre, Andre Vehreschild wrote: Could you also please specify the commit SHA your patch is supposed to apply to? At current mainline's HEAD it has several rejects which makes reviewing harder. I just tried and here it applies cleanly on mainline, except that I get a bunch of: Hunk #1 suc

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

Hi Paul, Am 23.09.24 um 10:26 schrieb Paul Richard Thomas: In addition to Andre's remarks, could you please tell us, when you resubmit, if this is a complete F2023 implementation of do concurrent. If not, what is missing? Regarding missing parts: still to do is actually privatizing (with or wi

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

Hi all, as a background – Anuj, did this as part of his Google Summer of Code project (thanks!). As I looked as various drafts, I would be happy if someone else could have a look as well, as I probably start skipping over things and, hence, as miss potential issues … A bit hidden in the patch i

[Patch] OpenMP: Add support for 'self_maps' to the 'require' directive

Add support of the 'self_maps' clause in 'omp requires', an OpenMP 6 feature but added here mostly as part of the on-going improvement of the unified-shared memory (USM) handling. Comments, remarks concerns before I commit it? * * * Regarding USM, there is on one hand the hardware: - some hard

OpenMP: Fix omp_get_device_from_uid, minor cleanup (was: Re: [Patch][v2] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines)

Hi Thomas, hello all, the attached follow-up patch does: * It fixes an issue (thinko) related to Fortran and \0 terminated, which fails for at least substring strings. * Includes some minor fixes, e.g. ensuring the device is initialized in omp_get_uid_from_device, the superfluous 'omp_', or

[wwwdocs][Patch] gcc-15: Fortran - mention -funsigned + PowerPC Darwin IEEE module support

Hi all, I thought it makes sense to have a look at what went into GCC 15 to update the Fortran section. However, while several bugs were fixed (and extended some features a tiny bit) [hooray!], I did not really see many newsworthy features. Comments, remarks to, approval of the attached wwwdocs

Re: [Patch][v2] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

/ (routine + nvptx/gcn offload specific) which makes it easier to read. Thanks, Tobias Tobias Burnus  wrote: Minor update – addressing the issues that Andre raised (thanks!): 'Add.' → 'New functions.' in the ChangeLog for 'fortran.c' and otherwise libgomp.texi changes,

[Patch][v2] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

or the GPUs, which should help to reduce confusion. Any additional comments or suggestions? Tobias Tobias Burnus wrote: in order to know and potentially re-use a specific offload device (reproducibility, affinity wise close to a CPU (socket), …) a mapping between an (universal?) unique id

Re: [Patch] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

Hi Andre, thanks for reading the patch + commenting. Andre Vehreschild wrote: in the changelog of libgomp: * fortran.c (omp_get_uid_from_device_, omp_get_uid_from_device_8_): Add. "Add." what? Can you be more specific, i.e. is it just a dummy or prototype? Neither. It is a f

[Patch] OpenMP: Add get_device_from_uid/omp_get_uid_from_device routines

Hi all, in order to know and potentially re-use a specific offload device (reproducibility, affinity wise close to a CPU (socket), …) a mapping between an (universal?) unique identifier and the OpenMP device number is useful. Thus, TR13 added support for it. This is a collateral patch caused

[Patch] Fortran: Fixes to OpenMP 'interop' directive parsing support

This patch fixes a couple of issues, like a missing white-space gobbling after matching an expression. It also reorganizes some code to handle 'identifier_"string"' vs. 'identifier' better as there were some diagnostic issues. (OpenMP requires for 'fr' that the argument is either an identifie

[committed] fortran/openmp.cc: Fix var init and locus use to avoid uninit values [PR fortran/116661]

bcb7630ba330e Author: Tobias Burnus Date: Wed Sep 11 09:25:47 2024 +0200 fortran/openmp.cc: Fix var init and locus use to avoid uninit values [PR fortran/116661] gcc/fortran/ChangeLog: PR fortran/116661 * openmp.cc (gfc_match_omp_prefer_type):

[patch][v2] Fortran: Add OpenMP 'interop' directive parsing support

Now also supports the following (note the variable name): 'init(targetsync, target)' – and I fixed an ICE when the variable parsing failed. Comments before I commit it? Tobias Tobias Burnus wrote: This patch adds Fortran parsing support for OpenMP's 'interop' dire

[patch] Fortran: Add OpenMP 'interop' directive parsing support

This patch adds Fortran parsing support for OpenMP's 'interop' directive (which stops with a 'sorry' in trans-openmp.cc as the middle end support is still missing). Tested on x86-64-gnu-linux. Comments, suggestions, remarks? * * * Background: 'interop' makes it easier to call, e.g., a CUDA-

Re: [patch][v3] libgomp: Add interop types and routines to OpenMP's headers and module

v3: Changes: (A) The 'ret_code' arguments of omp_get_interop_{int,ptr,str} are actually 'optional'. That's something that got lost in at some point between OpenMP 5.2 and TR13 (I filed OpenMP spec Issue #4165 for it). When adding it, I noticed that two '…_async' function lacked the '= NULL'

[patch][v2a] libgomp: Add interop types and routines to OpenMP's headers and module

function. Tobias Am 21.08.24 um 20:27 schrieb Tobias Burnus: Nearly identical to v1, except that I realized that OpenMP permits to call those functions also from target regions. Hence, those also got those functions, including a use of omp_irc_other to make clear why it will fail … In ad

[patch] libgomp: Add interop types and routines to OpenMP's headers and module

This patch adds 'interop' to C/C++'s omp.h and Fortran's omp_lib.h and omp_lib module. The implementation should match OpenMP 5.1 (which added interop) and also TR13; the Fortran routine support is new in TR13. It also adds 'hsa' as foreign object enum/paramter, which is currently being added

Re: [PATCH, v3] OpenMP: Constructors and destructors for "declare target" static aggregates

tic-aggr-constructor-destructor-3.C for a reason why running constructors on the target is preferable to e.g. constructing on the host and then copying the resulting object to the target.) 2024-08-07 Julian Brown Tobias Burnus gcc/ChangeLog: * builtins.def (DEF_GOMP_BUILTIN_COMPILER): Define

[PATCH, v3] OpenMP: Constructors and destructors for "declare target" static aggregates

low-up patch. On Aug 1, 2024, Jakub Jelinek wrote: On Tue, Jul 30, 2024 at 10:51:56PM +0200, Tobias Burnus wrote: - char id[sizeof (SSDF_IDENTIFIER) + 1 /* '\0' */ + 32]; + tree name; ... I'd just use a single buffer here, char id[MAX (sizeof (SSDF_IDENTIFIER), sizeof (OMP_

Re: [PATCH] fortran: Fix a pasto in gfc_check_dependency

[static analyzer] Jakub Jelinek wrote: […] it is some proprietary static analyzer I want to point out that a under utilized static analyzer keeps scanning GCC: Coverity Scan. If someone has the time, I think it would be worthwhile to have a look at the reports. There are a bunch of persons

[committed] gfortran.dg/compiler-directive_2.f: Update dg-error (was: [Patch, v2] OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause [PR115559])

Follow up fix: As the !GCC$ attributes are now added in reverse order, the 'stdcall' vs. 'fastcall' in the error message swapped order: "Error: stdcall and fastcall attributes are not compatible" This didn't show up here with -m64 ("Warning: 'stdcall' attribute ignored") and I didn't run it wi

Re: [Patch, v2] OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause [PR11555]

Hi Andre, hi all, Andre Vehreschild wrote: yes, I could have looked harder 🙂 I wrote ;-) on purpose as this feature is somewhat hidden and writing 'dg-do compile' doesn't harm. In case of gcc/testsuite, the 'run' is also needed and were often missed (or rather caused by invalid variants su

Re: [Patch, v2] OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause [PR11555]

Hi Andre, Andre Vehreschild wrote: I am wondering why the testcase has no `!{ dg-do ... }` line. What will dejagnu do then? Sorry for the may be stupid question, but I never encountered a testcase without a dg-do line. It was the minimum for me. Well, then you need look harder ;-) In gcc/test

[Patch, v2] OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause [PR11555]

Updated patch - only change is to the testcase: * With the just posted patch for PR116107, array sections with offset work for 'link', hence, I updated the testcase. * For 'arr2', I added ref to the associated PR. I intent to commit it once PR116107 has been committed. T

[Patch] OpenMP/Fortran: Fix handling of 'declare target' with 'link' clause [PR11555]

Hi all, it turned out that 'declare target' with 'link' clause was broken in multiple ways. The main fix is the attached patch, i.e. namely pushing the variables already to the offload-vars list already in the FE. When implementing it, I noticed: * C has a similar issue when using nested funct

Re: [Patch, PR Fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak

Andre Vehreschild wrote: PS That's good news about the funding. Maybe we will get to see "built in" coarrays soon? You hopefully will see Nikolas work on the shared memory coarray support, if that is what you mean by "built in" coarrays. I will be working on the distributed memory coarray suppor

Re: [committed] nvptx, libgfortran: Switch out of "minimal" mode

Sandra Loosemore wrote: On 6/6/24 06:06, Tobias Burnus wrote: +@item I/O within OpenMP target regions and OpenACC compute regions is supported +  using the C library @code{printf} functions. +  Additionally, the Fortran @code{print}/@code{write} statements are +  supported within

Re: [committed] nvptx, libgfortran: Switch out of "minimal" mode

Hi Thomas, regarding the commit r15-1070-g3a4775d4403f2e / https://gcc.gnu.org/r15-1070 First, thanks for adding I/O support to nvptx offloading. I have a wording nit, to be confirmed by a native speaker: --- a/libgomp/libgomp.texi +++ b/libgomp/libgomp.texi ... +@item I/O within OpenMP tar

[wwwdocs][patch] gcc-15/changes.html: Fortran - mention F2023 logical-kind additions

Let's make https://gcc.gnu.org/gcc-15/changes.html a bit more useful … While there were several useful Fortran commits already, only one seems to be about a new feature. Thus, document selected_logical_kind and the ISO_FORTRAN_ENV additions. Comments or suggestions before I commit it? Tobias

Re: [Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single

Hi Bernhard, rep.dot@gmail.com wrote: library such as @url{http://opencoarrays.org} needs to be linked. Maybe use https? Works, but as the certificate is not valid, it requires to ignore the errors in a browser, which is a worse user experience. The error is, e.g., "curl: (60) SSL cer

[Patch] Fortran: Fix SHAPE for zero-size arrays

That is for https://gcc.gnu.org/PR115150 – a GCC 12/13/14/15 regression, caused when switching from a libgomp call to inline code and missing the corner case of zero-size arrays ... OK for mainline + all affected branches? Tobias Fortran: Fix SHAPE for zero-size arrays PR fortran/115150 gcc

[Patch] Fortran: invoke.texi - link to OpenCoarrays.org + mention libcaf_single

I noticed that gfortran's coarray support did not link to the http://www.opencoarrays.org/ As that library is needed to support parallelization, it makes sense to have the link. Motivated by someone claiming at ISC-HPC that GCC only supports a single image. And also motivated by Damian's p

Re: Mattermost discussion on PR98426

Hi Bernhard, hello all, Bernhard Reutner-Fischer wrote: PS: unfortunately the git branch ( https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool ) mentioned in mail (I) lived in the old git, before we switched to git, and i fear that branch maybe got lost. Try gcc

Generated files in libgfortran for Fortran intrinsic procedures (was: Updated Sourceware infrastructure plans)

Hi Janne, Janne Blomqvist wrote: back when I was active I did think about this issue. IMHO the best of my ideas was to convert these into C++ templates. I think this will work – but we have to be super careful: With C++, there is the problem that we definitely do not want to add dependency o

[Patch] Fortran: List-directed read - accept again tab as alternative to space as separator [PR114304] (was: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not a

Jerry D wrote: See attached updated patch. It turned rather quickly out that this patch – committed as r14-9822-g93adf88cc6744a – caused regressions. Namely, real-world code use tab(s) as separator instead of spaces. [For instance, PR114304 which contains a named-list input file from SPEC

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, hello world, Jerry D wrote: On 4/5/24 10:47 AM, Jerry D wrote: On 4/4/24 2:41 PM, Tobias Burnus wrote: I think for the current testcases, I like the patch – the question is only what's about:    ',3' as input for 'comma'   (or '.3' as inpu

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, I think for the current testcases, I like the patch – the question is only what's about:   ',3' as input for 'comma'   (or '.3' as input for 'point') For 'point' – 0.3 is read and ios = 0 (as expected) But for 'comma': * GCC 12 reads nothing and has ios = 0. * GCC 13/mainline has an

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

Hi Jerry, Jerry D wrote: The attached log entry and patch (git show) fixes this issue by adding logic to handle spaces in eat_separators. One or more spaces by themselves are a valid separator. So in this case we look at the character following the spaces to see if it is a comma or semicolon.

Re: OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing

Hi all, hi Thomas & Chung-Lin, Thomas Schwinge wrote: But I realized another thing: don't we have to handle the 'readonly' modifier also in Fortran module files, that is, next to the OpenACC 'declare' 'copyin' handling in 'gcc/fortran/module.cc': 'AB_OACC_DECLARE_COPYIN' etc.? I bet so; it is

Re: OpenACC 2.7: front-end support for readonly modifier: Add basic OpenACC 'declare' testing

Hi all, hi Thomas & Chung-Lin, Thomas Schwinge wrote: But I realized another thing: don't we have to handle the 'readonly' modifier also in Fortran module files, that is, next to the OpenACC 'declare' 'copyin' handling in 'gcc/fortran/module.cc': 'AB_OACC_DECLARE_COPYIN' etc.? I bet so; it is

Re: [PATCH, OpenACC 2.7] struct/array reductions for Fortran

Hi Chung-Lin, hi Thomas, hello world, some thoughts glancing at the patch. Chung-Lin Tang wrote: There is still some shortcomings in the current state, mainly that only explicit-shaped arrays can be used (like its C counterpart). Anything else is currently a bit more complicated in the middle

Re: [Patch] OpenMP/Fortran: Fix defaultmap(none) issue with dummy procedures [PR114283]

Jakub Jelinek wrote: So firstprivate clause handling remaps them then if declare target indirect is used? If so, the patch looks reasonable to me. [I have now updated the patch to turn the testcase to ensure that is also keeps works at runtime.] OpenMP leaves it a bit open when the remapping

[Patch] OpenMP/Fortran: Fix defaultmap(none) issue with dummy procedures [PR114283]

Using dummy procedures in a target region with 'defaultmap(none)' leads to: Error: 'g' not specified in enclosing 'target' and this cannot be fixed by using 'firstprivate' as non-pointer dummy routines are rejected as "Error: Object 'g' is not a variable". Fixed by doing the same for mapping

[Patch] Fortran/Openmp: Use OPT_Wopenmp for gfc_match_omp_depobj warning

When checking something else, I noticed that there was one warning in openmp.cc that did not use OPT_Wopenmp. I intent to commit the attached patch later today as obvious. Tobias Fortran/Openmp: Use OPT_Wopenmp for gfc_match_omp_depobj warning gcc/fortran/ChangeLog: * openmp.cc (gfc_match_om

Re: [PATCH v2] openmp, fortran: Add Fortran support for indirect clause on the declare target directive

} +! { dg-xfail-run-if "Requires libgomp bug fix pending review" { offload_device } } Thanks, Tobias On 06/02/2024 9:03 am, Tobias Burnus wrote: LGTM. I just wonder whether there should be a value test and not just a does-not-crash-when-called test for the latter testcase, i.e. +++

Re: [PATCH v2] openmp, fortran: Add Fortran support for indirect clause on the declare target directive

Kwok Cheung Yeung wrote: As previously discussed, this version of the patch adds code to emit a warning when a directive like this: !$omp declare target indirect(.true.) is encountered (i.e. a target directive containing at least one clause, but no to/enter clause, which appears to violate th

Re: [PATCH] openmp, fortran: Add Fortran support for indirect clause on the declare target directive

Kwok Cheung Yeung wrote: This patch adds support for the indirect clause on the OpenMP 'declare target' directive in Fortran. As with the C and C++ front-ends, this applies the 'omp declare target indirect' attribute on affected function declarations. The C test cases have also been translated

Re: Open MP offloading

Hi, Rheinhardt Matthias wrote: at the moment, offloading Open MP workshare section is not supported, nor can implicit do-loops from expressions with array syntax be delt with in another way for offloading. Are there any plannings to lift this restriction, which is rather severe for - in partic

Re: [PATCH 2/8] OpenMP: lvalue parsing for map/to/from clauses (C)

Julian Brown wrote: This patch adds support for parsing general lvalues ("locator list item types") for OpenMP "map", "to" and "from" clauses to the C front-end, similar to the previously-posted patch for C++. Such syntax is permitted for OpenMP 5.0 and above. It was previously posted for mainl

Re: [PATCH 1/8] OpenMP: lvalue parsing for map/to/from clauses (C++)

Am 05.01.24 um 13:23 schrieb Julian Brown: On Wed, 20 Dec 2023 15:31:15 +0100 Tobias Burnus wrote: Here's a rebased/retested version which fixes those bits (I haven't adjusted the libgomp.texi bit you noted yet, though). How does this look now? --- a/gcc/gimplify.cc +++ b/gcc/g

Re: [PATCH] libgfortran: Bugfix if not define HAVE_ATOMIC_FETCH_ADD

On 22.12.23 03:36, Lipeng Zhu wrote: This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is not defined in dec_waiting_unlocked function. libgfortran/ChangeLog: * io/io.h (dec_waiting_unlocked): Use __gthread_rwlock_wrlock/__gthread_rwlock_unlock or __gthread_mutex_lock/_

Re: [PATCH v7 5/5] OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc

Hi Julian, On 20.12.23 22:29, Julian Brown wrote: Thanks for review! Here's a new version of the patch which hopefully addresses this round of comments. Thanks for the patch. LGTM now. Tobias On Tue, 19 Dec 2023 16:41:54 +0100 Tobias Burnus wrote: On 16.12.23 14:25, Julian Brown

Re: [PATCH 1/8] OpenMP: lvalue parsing for map/to/from clauses (C++)

On 05.09.23 21:28, Julian Brown wrote: This patch supports "lvalue" parsing (or "locator list item type" parsing) for several OpenMP clause types for C++, as required for OpenMP 5.0 and above. It is based on the version committed to the og13 branch, posted here: https://gcc.gnu.org/pipermail

Re: [PATCH 1/5] OpenMP, NVPTX: memcpy[23]D bias correction

Hi Julian & Thomas, the patch LGTM - and seemingly also Thomas is somewhat fine with it - and it includes the stand-alone testcase. * * * I guess, you don't know the answer to Thomas question, i.e. whether that's a bug in CUDA or in our use of the CUDA API? CUDA's spec itself, https://docs.nvi

Re: [PATCH v7 5/5] OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc

Hi Julian, On 16.12.23 14:25, Julian Brown wrote: OpenMP/OpenACC: Reorganise OMP map clause handling in gimplify.cc This patch has been separated out from the C++ "declare mapper" support patch. It contains just the gimplify.cc rearrangement work, mostly moving gimplificati

Re: [PATCH v7 4/5] OpenMP/OpenACC: Unordered/non-constant component offset runtime diagnostic

On 19.08.23 00:47, Julian Brown wrote: This patch adds support for non-constant component offsets in "map" clauses for OpenMP (and the equivalants for OpenACC), which are not able to be sorted into order at compile time. Normally struct accesses in such clauses are gathered together and sorted i

RE: [PATCH v7] libgfortran: Replace mutex with rwlock

Hi, Thomas Schwinge wrote:   On 2023-12-14T02:28:22+, "Zhu, Lipeng" wrote: On 2023/12/14 4:52, Thomas Schwinge wrote: >> I've just filed > Would

[Patch] OpenMP: Minor '!$omp allocators' cleanup - and still: Re: [patch] OpenMP/Fortran: Implement omp allocators/allocate for ptr/allocatables

Hi Thomas & Jakub, I included a minor cleanup patch - but the rest is really a bunch of RFC. I intent to commit that patch as obvious, unless there are further comments. On 09.12.23 16:14, Jakub Jelinek wrote: There were 3 reasons to add GOMP_alloc (and 1 for GOMP_free): 1) when it was added,

Re: [PATCH v7 3/5] OpenMP: Pointers and member mappings

Hi Julian, On 07.12.23 18:24, Julian Brown wrote: On Wed, 6 Dec 2023 12:36:34 +0100 Tobias Burnus wrote: LGTM, except for: * The 'target exit data' handling - comments below - looks a bit fishy/inconsistent. ... Thus, I wonder whether that shouldn't be instead OMP_

  1   2   3   4   5   6   >