Re: [PATCH, v2] Fortran: fix minor issues with coarrays (extended)
Hi Harald,
I totally understand your confusion. I also had a hard time figuring what is
needed there. I got to restructure the code fragment and now only allow pure
*and* elemental intrinsic function and pure *and* elemental user-defined
functions (hoping that's the opposite of intrinsics) in a caf accessor. For all
others a temporary is to be created in the helper structure. I also added a
comment to clarify the intention. I think this is better now. Opinions?
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
On Fri, 4 Jul 2025 19:29:08 +0200
Harald Anlauf wrote:
> 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/coarray.cc
> @@ -700,7 +700,7 @@ check_add_new_component (gfc_symbol *type, gfc_expr
> *e, gfc_symbol *add_data)
> && !e->symtree->n.sym->attr.elemental
> && !(e->value.function.isym
> && (e->value.function.isym->pure
> -|| e->value.function.isym->elemental)))
> +&& e->value.function.isym->elemental)))
> /* Treat non-pure/non-elemental functions. */
> check_add_new_comp_handle_array (e, type, add_data);
> else
>
> Can you please elaborate?
>
> I understood the code comment in the way that any pure or elemental
> intrinsic should be handled in the else branch. Or do you have
> an example which is different?
>
> The change to trans-decl.cc (fix of decl) looks fine for me.
>
> Harald
>
>
> m 04.07.25 um 13:43 schrieb Andre Vehreschild:
> > 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 pointer
> > argument to an object in the source image's memory, which is not available
> > on the remote image where the accessor is executed. This patch fixes that
> > and also corrects the type in the decl of the ABI of team_number. It is of
> > the opaque type team_type aka void* now and not integer as formerly
> > declared.
> >
> > Regtest ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
> >
> > Regards,
> > Andre
> >
> > On Tue, 1 Jul 2025 12:54:49 -0700
> > Jerry D wrote:
> >
> >> 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 simple and obvious fixes)
> >>>
> >>> - an inconsistency between pure/elemental functions being either
> >>> non-intrinsic or intrinsic. Checking for the latter was likely missed
> >>> from the beginning.
> >>>
> >>> No new testcase.
> >>>
> >>> Regtested on x86_64-pc-linux-gnu. OK for mainline?
> >>>
> >>> Thanks,
> >>> Harald
> >>>
> >>
> >> Yes, OK, straight-forward.
> >>
> >> Thanks,
> >>
> >> Jerry
> >
> >
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 2ad3600f5756b4c50fd70efde6d965a0037eb833 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Fri, 4 Jul 2025 11:26:46 +0200
Subject: [PATCH] Fortran: Fix pure/elemental function treatment and
team_number parameter attribution.
gcc/fortran/ChangeLog:
* coarray.cc (check_add_new_component): Only allow pure
elemental (intrinsic) functions in a coarray accessor.
* trans-decl.cc (gfc_build_builtin_function_decls): The only
argument of team_number() is of type void* in the library ABI.
---
gcc/fortran/coarray.cc| 26 --
gcc/fortran/trans-decl.cc | 7 +++
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/gcc/fortran/coarray.cc b/gcc/fortran/coarray.cc
index ef8fd4e42d0..c611b539968 100644
--- a/gcc/fortran/coarray.cc
+++ b/gcc/fortran/coarray.cc
@@ -696,17 +696,23 @@ check_add_new_component (gfc_symbol *type, gfc_expr *e, gfc_symbol *add_data)
check_add_new_component (type, actual->expr, add_data);
break;
case EXPR_FUNCTION:
- if (!e->symtree->n.sym->attr.pure
- && !e->symtree->n.sym->attr.elemental
- && !(e->value.function.isym
- && (e->value.function.isym->pure
- || e->value.function.isym->elemental)))
- /* Treat non-pure/non-elemental functions. */
- check_add_new_comp_handle_array (e, type, add_data);
+ if ((e->symtree->n.sym->attr.pure
+ && e->symtree->n.sym->attr.elemental)
+ || (e->value.function.isym && e->value.function.isym->pure
+ && e->value.function.isym->elemental))
+ {
+ /* Onl
Re: [PATCH, v2] Fortran: fix minor issues with coarrays (extended)
Andre,
I still don't get it, and the present version made it worse for me...
So let's see what I was thinking. There are the following types of
functions:
(0) impure, non-elemental functions, which likely have side-effects
(1) pure functions (in the f95 sense), i.e. pure non-elemental
(2) pure elemental functions (in the f95 sense)
(3) impure elemental functions (>= f2008)
Note that I understand "pure elemental" being different from
"pure and elemental" as used in the comment: the first version
really means both pure and elemental, the second could be read
as either pure or elemental or pure elemental. A native speaker
may correct me if I am wrong...
Back to gfortran: we have in decl.cc::gfc_match_prefix
/* If IMPURE it not seen but the procedure is ELEMENTAL, mark it as
PURE. */
if (!seen_impure && current_attr.elemental && !current_attr.pure)
{
if (!gfc_add_pure (¤t_attr, NULL))
goto error;
}
This explains the possible attributes we should see.
The change to coarray.cc has:
case EXPR_FUNCTION:
- if (!e->symtree->n.sym->attr.pure
- && !e->symtree->n.sym->attr.elemental
- && !(e->value.function.isym
- && (e->value.function.isym->pure
- || e->value.function.isym->elemental)))
- /* Treat non-pure/non-elemental functions. */
- check_add_new_comp_handle_array (e, type, add_data);
+ if ((e->symtree->n.sym->attr.pure
+ && e->symtree->n.sym->attr.elemental)
+ || (e->value.function.isym && e->value.function.isym->pure
+ && e->value.function.isym->elemental))
+ {
+ /* Only allow pure and elemental function calls in a coarray
+accessor, because all other may have side effects or access
+pointers, which may not be possible in the accessor
running on
+another host. */
+ for (gfc_actual_arglist *actual = e->value.function.actual;
+ actual; actual = actual->next)
+ check_add_new_component (type, actual->expr, add_data);
+ }
else
- for (gfc_actual_arglist *actual = e->value.function.actual;
actual;
-actual = actual->next)
- check_add_new_component (type, actual->expr, add_data);
+ /* Extract the expression, evaluate it and add a temporary
with its
+ value to the helper structure. */
+ check_add_new_comp_handle_array (e, type, add_data);
If I read the comment in the if-branch and match it against my
expectation, I am confused. Why only "pure elemental"? Why not
allow simply "pure"? And wouldn't it be better to move the explaining
comment before the "if" to make it easier to read the following?
E.g. why does a pure non-elemental function need a temporary?
Thanks,
Harald
Am 07.07.25 um 10:40 schrieb Andre Vehreschild:
Hi Harald,
I totally understand your confusion. I also had a hard time figuring what is
needed there. I got to restructure the code fragment and now only allow pure
*and* elemental intrinsic function and pure *and* elemental user-defined
functions (hoping that's the opposite of intrinsics) in a caf accessor. For all
others a temporary is to be created in the helper structure. I also added a
comment to clarify the intention. I think this is better now. Opinions?
Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
Regards,
Andre
On Fri, 4 Jul 2025 19:29:08 +0200
Harald Anlauf wrote:
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/coarray.cc
@@ -700,7 +700,7 @@ check_add_new_component (gfc_symbol *type, gfc_expr
*e, gfc_symbol *add_data)
&& !e->symtree->n.sym->attr.elemental
&& !(e->value.function.isym
&& (e->value.function.isym->pure
- || e->value.function.isym->elemental)))
+ && e->value.function.isym->elemental)))
/* Treat non-pure/non-elemental functions. */
check_add_new_comp_handle_array (e, type, add_data);
else
Can you please elaborate?
I understood the code comment in the way that any pure or elemental
intrinsic should be handled in the else branch. Or do you have
an example which is different?
The change to trans-decl.cc (fix of decl) looks fine for me.
Harald
m 04.07.25 um 13:43 schrieb Andre Vehreschild:
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
WinMain???
To whom it may concern, I am attempting to use gfortran. I used the QuickStart installer to install it. I tried the following: $ gfortran MOD_GID.F90 and received an error about Winmain missing??? What does this mean and how do I fix it? (I come from Intel's Fortran compiler).\\Thanks, Ken
Re: [PATCH, v2] Fortran: fix minor issues with coarrays (extended)
On Mon, Jul 07, 2025 at 08:53:16PM +0200, Harald Anlauf wrote:
> Andre,
>
> I still don't get it, and the present version made it worse for me...
>
> So let's see what I was thinking. There are the following types of
> functions:
>
> (0) impure, non-elemental functions, which likely have side-effects
>
> (1) pure functions (in the f95 sense), i.e. pure non-elemental
>
> (2) pure elemental functions (in the f95 sense)
>
> (3) impure elemental functions (>= f2008)
It's now a bit more complicated. There are SIMPLE procedures,
but gfortran does not support that prefix yet.
> Note that I understand "pure elemental" being different from
> "pure and elemental" as used in the comment: the first version
> really means both pure and elemental, the second could be read
> as either pure or elemental or pure elemental. A native speaker
> may correct me if I am wrong...
>
> Back to gfortran: we have in decl.cc::gfc_match_prefix
>
> /* If IMPURE it not seen but the procedure is ELEMENTAL, mark it as PURE.
> */
> if (!seen_impure && current_attr.elemental && !current_attr.pure)
> {
> if (!gfc_add_pure (¤t_attr, NULL))
> goto error;
> }
>
> This explains the possible attributes we should see.
The standardese is
F2023, 15.9 Elemental procedures
...
An elemental subprogram has the prefix-spec ELEMENTAL. An
elemental subprogram is a pure subprogram unless it has the
prefix-spec IMPURE.
I think the rest of your observations/questions are spot-on.
--
steve
Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions
On Sun, Jul 06, 2025 at 09:09:53PM +0800, Yuao Ma wrote: > Hi Tobias, > > On 7/6/2025 6:34 PM, Tobias Burnus wrote: > > As that commit is from 2020 and 2.69 in from 2012, it seems as if your > > autoconf is too new. Can you re-check that the right version is at the > > beginning of the PATH? > > > > Note that there is a CI job that checks whether the generated files are > > in deed up to date, i.e. the current trunk should be fine unless someone > > has messed up. > > > > It is possible that autoconf 2.69 contains this commit, as we can see from > https://github.com/autotools-mirror/autoconf/commit/a1d8293f3bfa2516f9a0424e3a6e63c2f8e93c6e > that it has been backported to v2.69b - v2.69e. > > The main reason is that my devbox has autoconf2.69 (2.69-3.1) from Debian, > released on Sat, 19 Nov 2022 21:40:11 +0200, which includes the commit from > 2020. This version takes precedence over my compiled version. Once I switch > to my compiled version, the generation output functions as expected. > > > The other question is whether the autoconf version shouldn't be updated, > > given that 2.69 is quite old. > > Upgrading this basic component may seem like a major change, but opting for > the same version with a backported patch appears to be a better choice. > Please see https://gcc.gnu.org/install/prerequisites.html. That page specifically says "autoconf version 2.69"; not some 2.69-patch-level. Everyone using the same release prevents conflicting changes. -- steve
Re: [Ping, Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.
Ping!
On Thu, 26 Jun 2025 15:32:47 +0200
Andre Vehreschild wrote:
> Hi,
>
> I found a bug in the module cleanup expression at the end of the test. In the
> attached patch it is corrected.
>
> Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline?
>
> Regards,
> Andre
>
> On Wed, 25 Jun 2025 15:48:11 +0200
> Andre Vehreschild wrote:
>
> > Hi,
> >
> > Antony Lewis reported this issue and also proposed a patch, that removes the
> > was_finalized tracking. While this may lead to the desired effect for the
> > issue at hand, I don't believe that the was_finalized tracking code has been
> > there for no reason.
> >
> > This patch fixes the issue that also Antony found, but by ensuring the
> > expression stays allocated when used instead of being freeed.
> >
> > The test has been put into the asan directory of gfortran.dg and reliably
> > reports the issue without the fix. (With the fix, the asan is quite).
> >
> > Regtests ok on x86_64-pc-linxu-gnu / F41. Ok for mainline?
> >
> > Regards,
> > Andre
>
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
From 4f493d4fb08a479a0a2003ceb858aae7aa677859 Mon Sep 17 00:00:00 2001
From: Andre Vehreschild
Date: Wed, 25 Jun 2025 14:46:16 +0200
Subject: [PATCH] Fortran: Ensure finalizers are created correctly [PR120637]
Finalize_component freeed an expression that it used to remember which
components in which context it had finalized already. While it makes
sense to free the copy of the expression, if it is unused, it causes
issues, when comparing to a non existent expression. This is now
detected by returning true, when the expression has been used.
PR fortran/120637
gcc/fortran/ChangeLog:
* class.cc (finalize_component): Return true, when a finalizable
component was detect and do not free it.
gcc/testsuite/ChangeLog:
* gfortran.dg/asan/finalizer_1.f90: New test.
---
gcc/fortran/class.cc | 24 ---
gcc/testsuite/gfortran.dg/asan/finalize_1.f90 | 67 +++
2 files changed, 81 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/asan/finalize_1.f90
diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index df18601e45b..a1c6fafa75e 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -1034,7 +1034,7 @@ comp_is_finalizable (gfc_component *comp)
of calling the appropriate finalizers, coarray deregistering, and
deallocation of allocatable subcomponents. */
-static void
+static bool
finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
gfc_symbol *stat, gfc_symbol *fini_coarray, gfc_code **code,
gfc_namespace *sub_ns)
@@ -1044,14 +1044,14 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
gfc_was_finalized *f;
if (!comp_is_finalizable (comp))
-return;
+return false;
/* If this expression with this component has been finalized
already in this namespace, there is nothing to do. */
for (f = sub_ns->was_finalized; f; f = f->next)
{
if (f->e == expr && f->c == comp)
- return;
+ return false;
}
e = gfc_copy_expr (expr);
@@ -1208,8 +1208,6 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
final_wrap->ext.actual->next->next = gfc_get_actual_arglist ();
final_wrap->ext.actual->next->next->expr = fini_coarray_expr;
-
-
if (*code)
{
(*code)->next = final_wrap;
@@ -1221,11 +1219,14 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
else
{
gfc_component *c;
+ bool ret = false;
for (c = comp->ts.u.derived->components; c; c = c->next)
- finalize_component (e, comp->ts.u.derived, c, stat, fini_coarray, code,
- sub_ns);
- gfc_free_expr (e);
+ ret |= finalize_component (e, comp->ts.u.derived, c, stat, fini_coarray,
+ code, sub_ns);
+ /* Only free the expression, if it has never been used. */
+ if (!ret)
+ gfc_free_expr (e);
}
/* Record that this was finalized already in this namespace. */
@@ -1234,6 +1235,7 @@ finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
sub_ns->was_finalized->e = expr;
sub_ns->was_finalized->c = comp;
sub_ns->was_finalized->next = f;
+ return true;
}
@@ -2314,6 +2316,7 @@ finish_assumed_rank:
{
gfc_symbol *stat;
gfc_code *block = NULL;
+ gfc_expr *ptr_expr;
if (!ptr)
{
@@ -2359,14 +2362,15 @@ finish_assumed_rank:
sub_ns);
block = block->next;
+ ptr_expr = gfc_lval_expr_from_sym (ptr);
for (comp = derived->components; comp; comp = comp->next)
{
if (comp == derived->components && derived->attr.extension
&& ancestor_wrapper && ancestor_wrapper->expr_type != EXPR_NULL)
continue;
- finalize_component (gfc_lval_expr_from_sym (ptr), derived, comp,
- stat, fini_coarray, &block, sub_ns);
+ finalize_component (ptr_expr, derived,
Re: [Ping, Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.
On 7/7/25 8:39 AM, Andre Vehreschild wrote: Ping! OK for mainline. Thanks, Jerry On Thu, 26 Jun 2025 15:32:47 +0200 Andre Vehreschild wrote: Hi, I found a bug in the module cleanup expression at the end of the test. In the attached patch it is corrected. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre On Wed, 25 Jun 2025 15:48:11 +0200 Andre Vehreschild wrote: Hi, Antony Lewis reported this issue and also proposed a patch, that removes the was_finalized tracking. While this may lead to the desired effect for the issue at hand, I don't believe that the was_finalized tracking code has been there for no reason. This patch fixes the issue that also Antony found, but by ensuring the expression stays allocated when used instead of being freeed. The test has been put into the asan directory of gfortran.dg and reliably reports the issue without the fix. (With the fix, the asan is quite). Regtests ok on x86_64-pc-linxu-gnu / F41. Ok for mainline? Regards, Andre
Coarray shared memory testing
Hello all, I have done the following to test the collection of Andre's patches which implement the subject -lcaf_shmem: 1) Successfully compiled and executed Toon's random_weather.f90 program. The only question I have on this one is when I select an np value such that the slab size does not come out even, the program exits as expected with a STOP code. However, I think this is performed by the first image to hit the stop. It looks like execution of the other images may just be frozen. I wonder if there are constraints in the standard regarding using a STOP within multiple images where each image may be trying to execute it? Is this a race condition or invalid Fortran. Ctrl-C does exit the program. 2) I can build and run OpenCoarrays with this test version of gfortran. However, when I do the usual 'make test', the test program register_alloc_vector hangs in a bad way with execution burning CPU cycles. Outside the OpenCoarrays test environment it appears to run correctly. While testing this with valgrind also hangs. It appears that valgrind is inside some memory check routine. I do not know if it is valid to even try to use valgrind with multiple images. So this test may be invalid. 3) I want to get broader testing of this so I set up a testing branch at the following location where others can clone this and test. https://forge.sourceware.org/JerryD/gfortran-TEST This is a test only repository and I intend to delete it after a few weeks until I can set up a better gfortran testing repo that is maintained current to trunk. One may have to register with sourceware to access this, I have not checked. I would appreciate anyone willing to build and test this branch to help flush out any issues. Feedback and/or test results welcome. Regards, Jerry
Re: Coarray shared memory testing
Thanks. I'll try that tomorrow. Kind regards, Toon. On 7/7/25 23:00, Jerry D wrote: Hello all, I have done the following to test the collection of Andre's patches which implement the subject -lcaf_shmem: 1) Successfully compiled and executed Toon's random_weather.f90 program. The only question I have on this one is when I select an np value such that the slab size does not come out even, the program exits as expected with a STOP code. However, I think this is performed by the first image to hit the stop. It looks like execution of the other images may just be frozen. I wonder if there are constraints in the standard regarding using a STOP within multiple images where each image may be trying to execute it? Is this a race condition or invalid Fortran. Ctrl-C does exit the program. 2) I can build and run OpenCoarrays with this test version of gfortran. However, when I do the usual 'make test', the test program register_alloc_vector hangs in a bad way with execution burning CPU cycles. Outside the OpenCoarrays test environment it appears to run correctly. While testing this with valgrind also hangs. It appears that valgrind is inside some memory check routine. I do not know if it is valid to even try to use valgrind with multiple images. So this test may be invalid. 3) I want to get broader testing of this so I set up a testing branch at the following location where others can clone this and test. https://forge.sourceware.org/JerryD/gfortran-TEST This is a test only repository and I intend to delete it after a few weeks until I can set up a better gfortran testing repo that is maintained current to trunk. One may have to register with sourceware to access this, I have not checked. I would appreciate anyone willing to build and test this branch to help flush out any issues. Feedback and/or test results welcome. Regards, Jerry -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: WinMain???
I get this error if I compile and link a source file without an actual program, like: subroutine x write(8,*) 'Boe' end subroutine x > gfortran x.f90 C:/Users/markus/gcc/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/markus/gcc/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crt0_c.o):crt0_c.c:(.text.startup+0x2e): undefined reference to `WinMain' collect2.exe: error: ld returned 1 exit status Does this mimick your case? Regards, Arjen Op ma 7 jul 2025 om 21:20 schreef Ken Woolridge : > To whom it may concern, > > I am attempting to use gfortran. I used the QuickStart installer to > install it. I tried the following: > > $ gfortran MOD_GID.F90 > > and received an error about Winmain missing??? > > What does this mean and how do I fix it? (I come from Intel's Fortran > compiler).\\Thanks, > Ken >
