Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

On Sun, Aug 03, 2025 at 12:20:24PM +0100, Paul Richard Thomas wrote: First, the easy one: > + /* Match the binding name; depending on type (operator / generic) format > + it for future error messages into bind_name. */ This comment looks muddled. > + if (op_type == INTERFACE_GENERIC

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Paul, On 7/31/2025 6:02 AM, Paul Richard Thomas wrote: That's exactly how I had a mind to do it. You beat me to it :-( Just get on, polish the patch and add more tests. I've updated the patch with improvements to both the functionality and test cases. It should now work well for simple sc

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Hi Harald, Please find attached an updated patch for the generic statement. The module attribute in real module function realg is required by all other brands. gfortran compiles happily with it and so I have added it to the testcase. This is now PR121379. I have also posted a submodule meta-bug P

[PATCH] fortran: Set DECL_TLS_MODEL after processing a variable

Call set_decl_tls_model only after a variable has been fully processed, not in the middle of processing it. gcc/fortran/ PR fortran/107421 * trans-common.cc (build_common_decl): Call set_decl_tls_model after processing a variable. * trans-decl.cc (gfc_finish_var_de

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Hi Paul, While an error is correctly generated, the wording of the error message iand locus seems odd. I have a code that has module foo implicit none private generic, public :: bar => bar generic, private :: bar => bah ... end module % gfcx -c a_gen4.F90 a_gen4.

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

On Thu, Jul 31, 2025 at 01:34:14PM -0700, Steve Kargl wrote: > > It seems that > > module foo > implicit none > private > public bar > generic :: bar => bar, bah > end module > > is not accepted. > As a follow-up, this is accepted with your patch. module foo implicit none pr

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

On Wed, Jul 23, 2025 at 05:53:17PM +0100, Paul Richard Thomas wrote: > > > Regtests on x86_64/FC42 - OK for mainline? > Here's another testcase that fails. % gfcx -o z a_gen2.F90 && ./z 42.000 43.500 % gfcx -o z -DGEN a_gen2.F90 a_gen2.F90:9:21: 9 |generic :: ba

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

On Wed, Jul 23, 2025 at 05:53:17PM +0100, Paul Richard Thomas wrote: > > The attached implements the F2018 generic statement, which has the same > semantics as the typebound version but can appear in any specification > statement. > > As it says in the first comment in the patch, use is made of t

Re: [PATCH] fortran: Evaluate class function bounds in the scalarizer

Hi Mikael, The patch applies cleanly, regtests and fixes the problem, as advertised. It does likewise on 15-branch. Good for mainline and, I would suggest, backporting. Thanks for the patch. Paul On Wed, 30 Jul 2025 at 10:04, Mikael Morin wrote: > From: Mikael Morin > > This one may look l

Re: [PATCH] fortran: implement conditional expression for fortran 2023

Hi Yuao, That's exactly how I had a mind to do it. You beat me to it :-( Just get on, polish the patch and add more tests. Thanks Paul On Wed, 30 Jul 2025 at 15:53, Yuao Ma wrote: > Hi all, > > This patch introduces support for conditional expressions (also known as > ternary operators in s

[PATCH] fortran: implement conditional expression for fortran 2023

. Please take a look when you have a moment. Thanks in advance, YuaoFrom 8b0312442ade17f64ae7c8059daa3af46a0bceda Mon Sep 17 00:00:00 2001 From: Yuao Ma Date: Wed, 30 Jul 2025 22:38:57 +0800 Subject: [PATCH] fortran: implement conditional expression for fortran 2023 TBD gcc/fortran/ChangeLog:

[PATCH] fortran: Evaluate class function bounds in the scalarizer

From: Mikael Morin This one may look like a collection of obscure random changes. It started with the removal of an isolated array descriptor offset update, and the chain of regression fixes that followed completed it to the below. I have even found a testcase that is fixed by it. Regression-te

Re: [PATCH] fortran: implment split for fortran 2023

Le 30/07/2025 à 02:42, Yuao Ma a écrit : On 7/27/2025 8:51 PM, Mikael Morin wrote: Le 27/07/2025 à 13:46, Yuao Ma a écrit : On 7/27/2025 7:14 PM, Mikael Morin wrote: Le 27/07/2025 à 11:37, Yuao Ma a écrit : On 7/27/2025 5:19 PM, Mikael Morin wrote: +gfc_charlen_type +string_split (gfc_ch

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Hi Harald, >From a very quick perusal of the F2018 standard, I have come to the tentative conclusion that: (i) 'real module function realg (arg1, arg2)' is almost certainly a correct requirement, although both flang-new and gfortran compile happily without the module attribute; and (ii) As far as

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

On Tue, Jul 29, 2025 at 10:29:37PM +0200, Harald Anlauf wrote: > > - I am a little confused about the handling of the access specification. > After the first "public :: g", NAG complains about the > > generic, public :: g ... > > and only allows > > generic :: g ... > > Then duplicate pub

Re: [PATCH] fortran: implment split for fortran 2023

On 7/27/2025 8:51 PM, Mikael Morin wrote: Le 27/07/2025 à 13:46, Yuao Ma a écrit : On 7/27/2025 7:14 PM, Mikael Morin wrote: Le 27/07/2025 à 11:37, Yuao Ma a écrit : On 7/27/2025 5:19 PM, Mikael Morin wrote: +gfc_charlen_type +string_split (gfc_charlen_type stringlen, const CHARTYPE *str

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Hi Paul! Am 24.07.25 um 08:07 schrieb Paul Richard Thomas: I forgot to include subroutine tests. Please find attached the patch with updated testcases. Paul On Wed, 23 Jul 2025 at 17:53, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: Hi All, The attached implements the F2018 ge

Re: [PATCH] fortran: Remove useless elements count variable

On Sun, Jul 27, 2025 at 02:47:14PM +0200, Mikael Morin wrote: > From: Mikael Morin > > Regression-tested on x86_64-pc-linux-gnu. > OK for master? > Looks ok to me. Of course, the last time I reviewed one of your patches, polymorphism got in the way of what appeared to be straight forward clea

Re: [PATCH] fortran: implment split for fortran 2023

On 7/27/2025 8:51 PM, Mikael Morin wrote: Le 27/07/2025 à 13:46, Yuao Ma a écrit : On 7/27/2025 7:14 PM, Mikael Morin wrote: Le 27/07/2025 à 11:37, Yuao Ma a écrit : On 7/27/2025 5:19 PM, Mikael Morin wrote: +gfc_charlen_type +string_split (gfc_charlen_type stringlen, const CHARTYPE *str

Re: [PATCH] fortran: implment split for fortran 2023

Le 27/07/2025 à 13:46, Yuao Ma a écrit : On 7/27/2025 7:14 PM, Mikael Morin wrote: Le 27/07/2025 à 11:37, Yuao Ma a écrit : On 7/27/2025 5:19 PM, Mikael Morin wrote: +gfc_charlen_type +string_split (gfc_charlen_type stringlen, const CHARTYPE *string, +  gfc_charlen_type setlen, const

[PATCH] fortran: Remove useless elements count variable

From: Mikael Morin Regression-tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- The function gfc_array_init_size evaluates the number of array elements to a variable from a caller, but the single caller providing the variable actually doesn't use it. This change removes the variable and t

Re: [PATCH] fortran: implment split for fortran 2023

Hi Steve, On 7/27/2025 2:25 AM, Steve Kargl wrote: Thanks for the review! If the new patch looks good for trunk and there are no other objections, could you please help me merge it? I haven't committed a patch since the transition from subversion to git. I'm not paid to learn yet-another-SCCS

Re: [PATCH] fortran: implment split for fortran 2023

s to be redundant. Fixed.From 8e867ea3593f85cdec4dd1dfe5b6a8729612b8eb Mon Sep 17 00:00:00 2001 From: Yuao Ma Date: Sun, 27 Jul 2025 19:41:25 +0800 Subject: [PATCH] fortran: implment split for fortran 2023 This patch includes the implementation, documentation, and test case for SPLIT. gcc/fortra

Re: [PATCH] fortran: implment split for fortran 2023

Le 27/07/2025 à 11:37, Yuao Ma a écrit : On 7/27/2025 5:19 PM, Mikael Morin wrote: +gfc_charlen_type +string_split (gfc_charlen_type stringlen, const CHARTYPE *string, +  gfc_charlen_type setlen, const CHARTYPE *set, +  gfc_charlen_type pos, GFC_LOGICAL_4 back) +{ +  gfc_charlen_

Re: [PATCH] fortran: implment split for fortran 2023

); + can you provide the value of pos and stringlen in the error messages? Done.From d1c8a89d49f9b66bb9a434f0058180b21061df42 Mon Sep 17 00:00:00 2001 From: Yuao Ma Date: Sun, 27 Jul 2025 18:12:53 +0800 Subject: [PATCH] fortran: implment split for fortran 2023 This patch includes the implementatio

Re: [PATCH] fortran: implment split for fortran 2023

I forgot to add: +  else +    { +  if (pos < 1 || pos > (stringlen + 1)) +    runtime_error ("If BACK is present with the value true, the value of " +   "POS shall be in the range [1, LEN (STRING) + 1]"); + can you provide the value of pos and stringlen in the error messages?

Re: [PATCH] fortran: implment split for fortran 2023

On 7/27/2025 5:19 PM, Mikael Morin wrote: +gfc_charlen_type +string_split (gfc_charlen_type stringlen, const CHARTYPE *string, +  gfc_charlen_type setlen, const CHARTYPE *set, +  gfc_charlen_type pos, GFC_LOGICAL_4 back) +{ +  gfc_charlen_type i, j; + +  if (!back) +    { +  i

Re: [PATCH] fortran: implment split for fortran 2023

Le 27/07/2025 à 05:40, Yuao Ma a écrit : Hi Mikael, On 7/27/2025 3:57 AM, Mikael Morin wrote: Hello, here are a few more comments on the patch below. It's not ready yet, but the remarks should be easily addressed. Thanks for the thorough review! I've addressed the comments and attached a n

Re: [PATCH] fortran: implment split for fortran 2023

;); + +  for (i = pos - 1; i != 0; i--) +    { +  for (j = 0; j < setlen; j++) +        { +  if (string[i - 1] == set[j]) +    { +  return i; +    } Same here. Done. Thanks, YuaoFrom 06bd5eff1306a82f35e7a9f9ba0db7f1af415f98 Mon Sep 17 00:00:00 2001 From: Yuao

Re: [PATCH] fortran: implment split for fortran 2023

Hello, here are a few more comments on the patch below. It's not ready yet, but the remarks should be easily addressed. diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc index be984271d6a..c2a91c93d28 100644 --- a/gcc/fortran/trans-intrinsic.cc +++ b/gcc/fortran/trans

Re: [PATCH] fortran: implment split for fortran 2023

On Sat, Jul 26, 2025 at 11:57:50PM +0800, Yuao Ma wrote: > > On 7/26/2025 11:25 PM, Steve Kargl wrote: > > On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote: > > > + add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE, > > > + BT_UNKNOWN, 0, GFC_STD_F2023, > > > + gfc_check_split,

Re: [PATCH] fortran: implment split for fortran 2023

of the patch looks Ok. Thanks for the review! If the new patch looks good for trunk and there are no other objections, could you please help me merge it? Thanks, YuaoFrom 177549017521d4c5215ff0e18fdb3492c31796a4 Mon Sep 17 00:00:00 2001 From: Yuao Ma Date: Sat, 26 Jul 2025 23:45:55 +0800 Su

Re: [PATCH] fortran: implment split for fortran 2023

On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote: > > + add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE, > + BT_UNKNOWN, 0, GFC_STD_F2023, > + gfc_check_split, NULL, gfc_resolve_split, > + "string", BT_CHARACTER, dc, REQUIRED, INTENT_IN, > + "set"

[PATCH] fortran: implment split for fortran 2023

e any issues. Users will still have the flexibility to choose their preferred method. Please take a look when you have a moment! Thanks, YuaoFrom 3fb261141dbc61296adb9c9361bafcd9922ad8bd Mon Sep 17 00:00:00 2001 From: Yuao Ma Date: Sat, 26 Jul 2025 20:59:26 +0800 Subject: [PATCH] fortran: imp

Re: [Patch, fortran] PR121182 - F2018 GENERIC statement is missing

I forgot to include subroutine tests. Please find attached the patch with updated testcases. Paul On Wed, 23 Jul 2025 at 17:53, Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > Hi All, > > The attached implements the F2018 generic statement, which has the same > semantics as the typ

Re: [PATCH] Fortran: fix passing of character length of function to procedure [PR121203]

Am 22.07.25 um 23:54 schrieb Jerry D: On 7/22/25 11:28 AM, Harald Anlauf wrote: Dear all, the attached patch fixes a long-standing issue with legacy code, where an assumed-length character function is passed as actual argument to a procedure, and when there is no explicit interface. The solutio

[Patch, fortran] PR121182 - F2018 GENERIC statement is missing

Hi All, The attached implements the F2018 generic statement, which has the same semantics as the typebound version but can appear in any specification statement. As it says in the first comment in the patch, use is made of the existing, typebound matching functions to obtain access-spec and gener

Re: [PATCH] Fortran: fix passing of character length of function to procedure [PR121203]

On 7/22/25 11:28 AM, Harald Anlauf wrote: Dear all, the attached patch fixes a long-standing issue with legacy code, where an assumed-length character function is passed as actual argument to a procedure, and when there is no explicit interface. The solution is to do the same as in the case when

[PATCH] Fortran: fix passing of character length of function to procedure [PR121203]

2001 From: Harald Anlauf Date: Tue, 22 Jul 2025 20:16:16 +0200 Subject: [PATCH] Fortran: fix passing of character length of function to procedure [PR121203] PR fortran/121203 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_procedure_call): Obtain the character length of an assumed character

Re: [PATCH] Fortran: fix bogus runtime error with optional procedure argument [PR121145]

Hi Andre, Am 18.07.25 um 21:41 schrieb Andre Vehreschild: Hi Harald, that looks fine to me. Ok to commit and backport. Thanks for the patch. pushed as r16-2355-g8f9450505f8244 so far. Thanks for the review! Harald - Andre Andre Vehreschild * ve...@gmx.de Am 18. Juli 2025 21:19:00 schrieb

Re: [PATCH] Fortran: fix bogus runtime error with optional procedure argument [PR121145]

Hi Harald, that looks fine to me. Ok to commit and backport. Thanks for the patch. - Andre Andre Vehreschild * ve...@gmx.de Am 18. Juli 2025 21:19:00 schrieb Harald Anlauf : Dear all, the attached simple and obvious patch fixes an erroneous runtime check with -fcheck=pointer when passing a no

[PATCH] Fortran: fix bogus runtime error with optional procedure argument [PR121145]

Mon Sep 17 00:00:00 2001 From: Harald Anlauf Date: Fri, 18 Jul 2025 21:12:03 +0200 Subject: [PATCH] Fortran: fix bogus runtime error with optional procedure argument [PR121145] PR fortran/121145 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_procedure_call): Do not create pointer check for

Re: *** SPAM *** Re: [PATCH] fortran: Factor array descriptor references

Le 16/07/2025 à 00:05, Steve Kargl a écrit : On Sun, Jul 13, 2025 at 10:59:32AM +0200, Mikael Morin wrote: Regression tested on x86_64-pc-linux-gnu. OK for master? Yes, with one observation below. diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index 1561936daf1..af62e

Re: [PATCH] fortran: Factor array descriptor references

On Sun, Jul 13, 2025 at 10:59:32AM +0200, Mikael Morin wrote: > > Regression tested on x86_64-pc-linux-gnu. > OK for master? > Yes, with one observation below. > diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc > index 1561936daf1..af62e17442b 100644 > --- a/gcc/fortran/tran

Re: [Patch, fortran] PR121060 - ICE when argument is associate name created from type-bound operator result

OK Paul, thanks. We probably ought to back port it to 15 On Tue, Jul 15, 2025, 9:22 AM Paul Richard Thomas < paul.richard.tho...@gmail.com> wrote: > At first this PR looked as if it was going to be one of those horrible > typebound procedure/operator tangles. However, it turned out that this was

[Patch, fortran] PR121060 - ICE when argument is associate name created from type-bound operator result

At first this PR looked as if it was going to be one of those horrible typebound procedure/operator tangles. However, it turned out that this was entirely down to the attempt to extract the specific procedure for the ASSOCIATE name during parsing. Returning NULL before expression resolution fixed

[PATCH] fortran: Factor array descriptor references

Regression tested on x86_64-pc-linux-gnu. OK for master? -- >8 -- Save subexpressions of array descriptor references to variables, so that all the expressions using the descriptor as base object benefit from a simplified reference using the variables. This limits the size of the expressions gen

Re: [Patch] Fortran/OpenACC: Permit PARAMETER as 'var' in clauses (+ ignore)

On 7/11/25 10:36 PM, Tobias Burnus wrote: Now, finally pushed as r16-2213-g451b6dbf475959. Tobias On June 27, 2025, Tobias Burnus wrote: Background: In real-world code, one can find:    !$ACC DECLARE COPYIN(c1es, c2es, ...) as here for the ICON weather model. This clearly implies that other co

Re: [Patch] Fortran/OpenACC: Permit PARAMETER as 'var' in clauses (+ ignore)

Now, finally pushed as r16-2213-g451b6dbf475959. Tobias On June 27, 2025, Tobias Burnus wrote: Background: In real-world code, one can find: !$ACC DECLARE COPYIN(c1es, c2es, ...) as here for the ICON weather model. This clearly implies that other compilers accept and, potentially, require th

Re: [Patch, Fortran, Coarray, PR88076, v2] Add a shared memory multi process coarray library.

On 7/10/25 2:27 AM, Andre Vehreschild wrote: Hi all, after Jerry had the idea to use OpenCoarray's tests to also test caf_shmem, a few issue arose. Those have been fixed now in the updated patch-series. I have put all patches into one mail to allow the CIs to pick them all up and hopefully test

Re: [Patch, fortran] PR106135 - Implement F2018 IMPORT statements

Thanks, Jerry. Pushed as r16-2189. Note however that s/pr106135/pr106035 is required throughout. I will attend to it tomorrow. Paul On Mon, 23 Jun 2025 at 19:27, Jerry D wrote: > On 6/23/25 9:43 AM, Paul Richard Thomas wrote: > > Hello All, > > > > I was mulling over the F2018 status of gfort

Re: [Patch, Fortran, Coarray, PR88076, v2] Add a shared memory multi process coarray library.

Am 10.07.25 um 11:27 schrieb Andre Vehreschild: Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Did you run extensive tests on all potential race conditions, and fix the resulting fallout? If you did, please post your test cases and the results. Otherwise, https://gcc.gnu.org/piperm

Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

Hi Jerry, good you could build Toon's code. Your idea of using the OpenCoarray tests to test caf_shmem made me think about how to do it the easiest. I came up with the following: 1. Pull a recent OpenCoarray source tree from Github or use a clean existing one. 2. Apply attached patch. 3. Crea

Re: [Patch, fortran] PR106135 - Implement F2018 IMPORT statements

Paul, Either resolve.cc has sufficiently evolved since you submitted your patch or the patch is somehow mangled. When I apply it to my tree for resolve.cc, I see Hunk #1 succeeded at 3919. Hunk #2 succeeded at 4223. Hunk #3 succeeded at 7940 (offset -28 lines). Hunk #4 succeeded at 8068 (offset

Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

On 7/4/25 19:51, Jerry D wrote: On 7/4/25 5:12 AM, Andre Vehreschild wrote: Hi all, attached patches goes on top of other 6 caf_shmem coarray patches and fixes missing includes esp. on non-Linux systems. I have tested this on a FreeBSD, which is very time consuming due to it being fully virtu

Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

On 7/4/25 5:12 AM, Andre Vehreschild wrote: Hi all, attached patches goes on top of other 6 caf_shmem coarray patches and fixes missing includes esp. on non-Linux systems. I have tested this on a FreeBSD, which is very time consuming due to it being fully virtualized on my system. Regtests ok o

Re: [PATCH] Fortran: fix minor issues with coarrays (extended)

Andre, either your patch to coarray.cc is wrong, or the comment in the code is not concise, or I am too dense to understand the intent of the change: diff --git a/gcc/fortran/coarray.cc b/gcc/fortran/coarray.cc index ef8fd4e42d0..01aac581a74 100644 --- a/gcc/fortran/coarray.cc +++ b/gcc/fortran/

Re: [Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

Am 04.07.25 um 14:12 schrieb Andre Vehreschild: Regtests ok on x86_64-pc-linux-gnu and aarch64-unknown-freebsd14.3. Ok for mainline? The whole patch set needs including the library needs rigorous and extensive testing against race conditions, as outlined in https://gcc.gnu.org/pipermail/fortran

[Patch, Fortran, Coarray, PR88076, v1] 7/6 Add a shared memory multi process coarray library.

+0200 Subject: [PATCH] Fortran: Fix includes in caf_shmem (esp. for BSDs) [PR88076] PR fortran/88076 libgfortran/ChangeLog: * caf/shmem.c: Remove declaration of environment. * caf/shmem/allocator.h: Fix required includes. * caf/shmem/hashmap.h: Same. * caf/shmem/shared_memory.h: Same. * caf

Re: [PATCH] Fortran: fix minor issues with coarrays (extended)

, > > Harald > > > > Yes, OK, straight-forward. > > Thanks, > > Jerry -- Andre Vehreschild * Email: vehre ad gmx dot de From 4b9181aab9fc1b3982724a442b19c69458459b5f Mon Sep 17 00:00:00 2001 From: Andre Vehreschild Date: Fri, 4 Jul 2025 11:26:

Re: [PATCH] fortran: Add the preliminary code of MOVE_ALLOC arguments

On Thu, Jul 03, 2025 at 10:12:52PM +0200, Mikael Morin wrote: > From: Mikael Morin > > Regression-tested on aarch64-unknown-linux-gnu. > OK for master? > Yes. Almost looks obvious once someone finds and fixes the issue. Thanks for the patch. -- Steve

[PATCH] fortran: Add the preliminary code of MOVE_ALLOC arguments

From: Mikael Morin Regression-tested on aarch64-unknown-linux-gnu. OK for master? -- >8 -- Add the preliminary code produced for the evaluation of the FROM and TO arguments of the MOVE_ALLOC intrinsic before using their values. Before this change, the preliminary code was ignored and dropped, l

Re: [PATCH] Fortran: fix minor issues with coarrays

Am 01.07.25 um 21:54 schrieb Jerry D: On 7/1/25 12:51 PM, Harald Anlauf wrote: Dear all, the attached patch fixes the following minor issues found by running f951 under valgrind for the just added new testcases coindexed_6.f90 and coindexed_7.f90: - minor front-end memleaks with non-freed stri

Re: [PATCH] Fortran: fix minor issues with coarrays

On 7/1/25 12:51 PM, Harald Anlauf wrote: Dear all, the attached patch fixes the following minor issues found by running f951 under valgrind for the just added new testcases coindexed_6.f90 and coindexed_7.f90: - minor front-end memleaks with non-freed strings and lost GMP variables  (these are

[PATCH] Fortran: fix minor issues with coarrays

2001 From: Harald Anlauf Date: Tue, 1 Jul 2025 21:41:53 +0200 Subject: [PATCH] Fortran: fix minor issues with coarrays gcc/fortran/ChangeLog: * coarray.cc (check_add_new_component): Treat pure and elemental intrinsic functions the same as non-intrinsic ones. (create_caf_add_data_parameter_type

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Andre, I've never built gcc for aarch64-freebsd. I was going to suggest doing the full bootstrap, but that seems to be too slow. On amd64, I use ../gcc/configure --prefix=$WDIR \ --enable-languages=c,c++,fortran,lto \ --enable-bootstrap \ --disable-nls \ --disable-libssp \ --disa

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Steve, how to you get a recent gcc compile on aarch64-freebsd-14.3 ? I am seeing several issues in core libraries of gcc that are far away from where I touched the compiler. I am configuring with: configure --disable-multilib\ --enable-stage1-languages=c,fortran,c++\

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 06:54:53PM -0700, Steve Kargl wrote: > On Sun, Jun 29, 2025 at 03:30:21PM -0700, Steve Kargl wrote: > > On Sun, Jun 29, 2025 at 11:07:31AM -0700, Steve Kargl wrote: > > > On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote: > > > > > > > > === gfortr

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Yet, another head scratcher. ../../../gcc/libgfortran/caf/shmem/supervisor.c:235:27: error: 'environ' undeclared (first use in this function) 235 | for (char **e = environ; *e; ++e, ++n) | ^~~ I see 'extern char **environ;' in shmem.c. Is this sup

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 07:06:57PM -0700, Steve Kargl wrote: > On Sun, Jun 29, 2025 at 06:54:53PM -0700, Steve Kargl wrote: > > > > /usr/local/bin/ld: cannot find -lcaf_shmem: No such file or directory > > collect2: error: ld returned 1 exit status > > compiler exited with status 1 > > > > The fre

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 06:54:53PM -0700, Steve Kargl wrote: > > /usr/local/bin/ld: cannot find -lcaf_shmem: No such file or directory > collect2: error: ld returned 1 exit status > compiler exited with status 1 > > The freshly built gfortran cannot find the libcaf_shmem.a. > % find . -name \*li

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 03:30:21PM -0700, Steve Kargl wrote: > On Sun, Jun 29, 2025 at 11:07:31AM -0700, Steve Kargl wrote: > > On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote: > > > > > > === gfortran Summary === > > > > > > # of expected passes73149 > > >

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 11:07:31AM -0700, Steve Kargl wrote: > On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote: > > > > === gfortran Summary === > > > > # of expected passes73149 > > # of unexpected failures522 It seems that something is mucking wi

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 08:36:38PM +0200, Andre Vehreschild wrote: > > I would do git am pr88076_v1_1.patch or patch -p1 each of the patch files. Then they go where they ought to be. Thanks. I needed -p1 for v1_5 and v1_6. > Pro tip: create a new branch before doing the git am, then you can ju

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Steve, I would do git am pr88076_v1_1.patch or patch -p1 each of the patch files. Then they go where they ought to be. Pro tip: create a new branch before doing the git am, then you can just switch back to master when desired. - Andre Andre Vehreschild * ve...@gmx.de Am 29. Juni 2025 20:2

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote: > > Just applied the 6 patch (with the update part 5). I'm > seeing a significant increase in the number of failures > in 'make check-fortran' testing. > Just re-applied your patches in the top-level gcc/ directory. I was expecting mo

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Sun, Jun 29, 2025 at 10:35:39AM -0700, Steve Kargl wrote: > > === gfortran Summary === > > # of expected passes73149 > # of unexpected failures522 > # of expected failures 343 > # of unresolved testcases 78 > # of unsupported tests 94

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Thu, Jun 26, 2025 at 10:15:01AM +0200, Andre Vehreschild wrote: > > I deem this library fit for educational and research use, > where small to medium sized problems are researched. I do > not expect it to support a long term running application, > because is does not join adjacent blocks in th

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/29/25 7:52 AM, Thomas Koenig wrote: Hi Jerry, real    0m7.426s user    0m47.602s sys    0m42.707s Do you know if these numbers are for a shared-memory MPI implementation or a traditional one? Best regards Thomas I believe it is traditional. I was using OpenCoarrays with mpich.

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On Tue, Jun 24, 2025 at 03:09:33PM +0200, Andre Vehreschild wrote: > > this series of patches (six in total) adds a new coarray backend library to > libgfortran. The library uses shared memory and processes to implement > running multiple images on the same node. The work is based on work starte

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Jerry, real    0m7.426s user    0m47.602s sys    0m42.707s Do you know if these numbers are for a shared-memory MPI implementation or a traditional one? Best regards Thomas

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/27/25 1:08 PM, Toon Moene wrote: On 6/27/25 17:41, Toon Moene wrote: Note: as the timeline at the top of the source implies, I have worked on this until early 2021. This means it compiled with gfortran 10 and 11. So the problem is probably introduced after these versions. [ Of course,

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/27/25 1:08 PM, Toon Moene wrote: On 6/27/25 17:41, Toon Moene wrote: Note: as the timeline at the top of the source implies, I have worked on this until early 2021. This means it compiled with gfortran 10 and 11. So the problem is probably introduced after these versions. [ Of course,

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/27/25 17:41, Toon Moene wrote: Note: as the timeline at the top of the source implies, I have worked on this until early 2021. This means it compiled with gfortran 10 and 11. So the problem is probably introduced after these versions. [ Of course, while I perused the Fortran 2018 standa

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/27/25 17:33, Jerry Delisle wrote: I am out of office at the moment. I do not get the ICE, but I did get errors about rank mismatching in four places. Jerry On Fri, Jun 27, 2025, 2:22 AM Andre Vehreschild > wrote: Hi Jerry, I can not compile the example fro

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

I am out of office at the moment. I do not get the ICE, but I did get errors about rank mismatching in four places. Jerry On Fri, Jun 27, 2025, 2:22 AM Andre Vehreschild wrote: > Hi Jerry, > > I can not compile the example from Toon. I get two issues: > > https://gcc.gnu.org/bugzilla/show_bug.c

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Jerry, I can not compile the example from Toon. I get two issues: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120843 and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847 Can you reproduce? - Andre On Thu, 26 Jun 2025 16:49:59 -0700 Jerry Delisle wrote: > Toon, thank you! I will give

[Patch] Fortran/OpenACC: Permit PARAMETER as 'var' in clauses (+ ignore)

Background: In real-world code, one can find: !$ACC DECLARE COPYIN(c1es, c2es, ...) as here for the ICON weather model. This clearly implies that other compilers accept and, potentially, require those. For better compatibility with real-world use, the just released OpenACC 3.4 now permits PARAME

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Toon, thank you! I will give it a try here so we can have some data points. Jerry On Thu, Jun 26, 2025, 2:08 PM Toon Moene wrote: > On 6/26/25 21:34, Thomas Koenig wrote: > > > Am 26.06.25 um 10:15 schrieb Andre Vehreschild: > > >> Hi Thomas, > >> > >>> I have a few questions. > >>> > >>> First

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/26/25 21:34, Thomas Koenig wrote: Am 26.06.25 um 10:15 schrieb Andre Vehreschild: Hi Thomas, I have a few questions. First, I see that your patch series does not use gfortran's descriptors for accessing coarrays via shared memory, as the original work by Nicolas did.  Can you comment

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Am 26.06.25 um 10:15 schrieb Andre Vehreschild: Hi Thomas, I have a few questions. First, I see that your patch series does not use gfortran's descriptors for accessing coarrays via shared memory, as the original work by Nicolas did. Can you comment on that? The ABI for invoking coarray fun

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Jerry, for the moment only the static library is configured in the build scripts. Therefore only that is build named libcaf_shmem.a That's completely correct and desired. I have asked the same question about performance or stress tests and got only the coarray_icar (link in the 0/6 mail).

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/26/25 12:22 AM, Andre Vehreschild wrote: Hi Jerry, thanks for testing. I have fixed IMO most of the whitespace issues in the patch attached to this mail: https://gcc.gnu.org/pipermail/fortran/2025-June/062349.html About the 32 vs. 64 bit versions of the libraries: I never got in touch with

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Andre, I used a clean build directory but don't recall if I reconfigured. I was 10 minutes away from leaving for the airport! I'll try again when I am back at base. Please, everyone else, don't hesitate to review and test. Regards Paul On Tue, 24 Jun 2025, 23:47 Andre Vehreschild, wrote:

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Thomas, > I have a few questions. > > First, I see that your patch series does not use gfortran's descriptors > for accessing coarrays via shared memory, as the original work by > Nicolas did. Can you comment on that? The ABI for invoking coarray functionality is sufficient for doing the job

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Jerry, thanks for testing. I have fixed IMO most of the whitespace issues in the patch attached to this mail: https://gcc.gnu.org/pipermail/fortran/2025-June/062349.html About the 32 vs. 64 bit versions of the libraries: I never got in touch with that. I am doing the same as for caf_single. In

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/24/25 11:49 PM, Andre Vehreschild wrote: Hi Jerry, thank you very much. Just try it. I can only imagine that Paul had a somehow corrupted build directory or left overs from some previous build. I am still wondering, that I got no automated mail from the build hosts, but I can imagine, that

Re: [PATCH] Fortran: fix ICE in verify_gimple_in_seq with substrings [PR120743]

Am 24.06.25 um 21:11 schrieb Steve Kargl: On Tue, Jun 24, 2025 at 09:00:46PM +0200, Harald Anlauf wrote: here's an obvious fix for a recent regression: substring offset calculations used a wrong type that crashed in gimplification. Andre basically OK'ed it in the PR, but here it is nevertheless

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/24/25 6:09 AM, Andre Vehreschild wrote: Hi all, this series of patches (six in total) adds a new coarray backend library to libgfortran. The library uses shared memory and processes to implement running multiple images on the same node. The work is based on work started by Thomas and Nico

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Andre, this series of patches (six in total) adds a new coarray backend library to libgfortran. The library uses shared memory and processes to implement running multiple images on the same node. The work is based on work started by Thomas and Nicolas Koenig. No changes to the gfortran compile

  1   2   3   4   5   6   7   8   9   10   >