Re: [PATCH] fortran: add optional lower arg to c_f_pointer

Oops, looks like I mess up a testcase name. Fixed in this version. On 8/6/2025 10:57 PM, Yuao Ma wrote: Hi Tobias, On 8/6/2025 4:32 PM, Tobias Burnus wrote: Hi Yuao, thanks for your patch. I have two nits: * There is no diagnostic for -std=f2018 (or lower);    can you add the 'gfc_notify_std

Re: [PATCH] fortran: add optional lower arg to c_f_pointer

Hi Tobias, On 8/6/2025 4:32 PM, Tobias Burnus wrote: Hi Yuao, thanks for your patch. I have two nits: * There is no diagnostic for -std=f2018 (or lower);   can you add the 'gfc_notify_std (GFC_STD_F2023' ? Done. Testcase added. * I have a minor documentation nit; current wording is   at

Re: [PATCH] fortran: cleanup duplicate tests for c_f_pointer_shape_driver; nfc

On 8/6/2025 5:20 PM, Tobias Burnus wrote: Hi Yuao, thanks for the patch. — I have one nit: Yuao Ma wrote: This patch cleans up a duplicate test driver. Regression-tested. OK for trunk? ... Subject: [PATCH] fortran: cleanup duplicate tests for   c_f_pointer_shape_driver; nfc '; nfc'? tes

Re: [PATCH] fortran: cleanup duplicate tests for c_f_pointer_shape_driver; nfc

Hi Yuao, thanks for the patch. — I have one nit: Yuao Ma wrote: This patch cleans up a duplicate test driver. Regression-tested. OK for trunk? ... Subject: [PATCH] fortran: cleanup duplicate tests for c_f_pointer_shape_driver; nfc '; nfc'? tests_2_driver and tests_4_driver are identical,

Re: [PATCH] fortran: add optional lower arg to c_f_pointer

Hi Yuao, thanks for your patch. I have two nits: * There is no diagnostic for -std=f2018 (or lower); can you add the 'gfc_notify_std (GFC_STD_F2023' ? * I have a minor documentation nit; current wording is at https://gcc.gnu.org/onlinedocs/gfortran/C_005fF_005fPOINTER.html Namely, ... Yu

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

With your updated patch addressing Steve's comments OK. We have time for minor tweaks if necessary. On 8/3/25 11:06 AM, Steve Kargl wrote: 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 / gen

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

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

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

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

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 CHARTYPE *set, +  gfc_charlen_typ

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

On 7/27/2025 5:43 PM, Mikael Morin wrote: 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 valu

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

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 new patch below. diff --git a/gcc/fortran

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

Hi Steve, 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, NULL, gfc_resolve_split, + "string", BT_CH

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"

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

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

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

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

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

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

Hi all, attached patch narrows the use of intrinsic functions in the caf accessor down to pure elemental functions. This is needed because functions that get extracted into the caf accessor routine, have no access to the source image's memory. E.g. team_number() is marked as pure, but takes a poin

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

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

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

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

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

Andre, I assumed that there would be some overhead, and perhaps bloat, if -fcoarray=single were made the default. With the introduction of a shmem runtime, changing the default is likely a GCC 17 change and not something we should pursue for GCC 16. Yes, I know that this uses shmem and not MPI.

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

Giving something new time to mature before making it the default is always a great policy. My suggestion is aspirational. I’m describing a dream that I hope can be the ultimate goal. There’s no need to rush into implementing my proposed vision. D On Tue, Jun 24, 2025 at 23:25 Andre Vehreschild

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

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 they get issues with a series of patches, that b

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

Hi Damian, hi Steve, enabling coarray-support by default has implications we need to consider. The memory footprint of a coarray enabled program is larger than the one of a non-coarray one. This is simply because the coarray token needs to be stored somewhere. Furthermore, I just yesterday figure

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

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. > > Regtested on x86_64-pc-linux-g

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

Damian, I submitted a patch a long time ago to make -fcoarray=single the default behavior. The patch made -fcoarray=none a NOP. With inclusion of a shmem implementation of the runtime parts, this might be the way to go. I'll leave that decision to Andre, Thomas, and Nicolas. I believe that the

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

If gfortran will have a shared-memory coarray implemented, it would be great to also drop the requirement to pass -fcoarray. Other compilers have trended in the direction of dropping the flag too, including Cray and NAG. Even all these years after Fortran 2008 introduced multi-image execution, I

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

Hi Andre, All six patches require git apply --whitespace=fix --ignore-space-change < ~/prs/Shared_Memory/pr88076_v1_x.patch to apply. The build fails with: Makefile:3848: caf/.deps/caf_error.Plo: No such file or directory make[2]: *** No rule to make target 'caf/.deps/caf_error.Plo'. Stop. make

  1   2   3   4   5   6   7   8   9   10   >