Hi Harald,
sorry for all the confusion. Probably my understanding of a pure
elemental routine is imperfect. I therefore first like to express what
I need an a caf-accessor. In a caf-accessor I have only access to data
that is "exported" to it via the add_data object. The data in there has
to be made available locally on the remote image in the accessor,
because the accessor can be executed on a remote image on a different
machine. This prevents access to data that is pointed to (including
allocated) or has an opaque type.
By using the pure && elemental flag I tried to mimic this. The rules
for which routines are pure and/or elemental are to complicated for me
at the moment. I just don't get all possible combinations into my head.
May be it is safest to enforce that every function call is evaluated on
the source image, thus preventing any misunderstandings.
Did that help? Shall I rephrase the commit to enforce source image
evaluation of functions? In my opinion that at least reduces code
complexity and one is on the safe side.
Regards,
Andre
On Mon, 7 Jul 2025 20:53:16 +0200
Harald Anlauf <anl...@gmx.de> 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)
>
> 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 <anl...@gmx.de> 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 <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
> >>>
> >>>
> >>
> >
> >
>
--
Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen
Tel.: +49 178 3837536 * ve...@gmx.de
