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 <jvdelis...@gmail.com> 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
