Hi Jerry,
thank you very much for the review.
I would love to fix the nits you found, but I don't see, what you see. Can you
elaborate? May be some mail client has removed something, or I am missing
something. Are you commenting on
> gfc_error (
> "%s argument at %L must be a scalar %s variable of at least kind %d",
that this is formatted like this, i.e. the string in the next line? That is
clang-format's doing. That formatter is getting worse in each iteration.
I see this in the second and third chunk of your comment, too. Is this what you
like me to fix? I just want to prevent overlooking some typo or the like.
Thanks again and regards,
Andre
On Sun, 13 Apr 2025 18:40:44 -0700
Jerry D <jvdelis...@gmail.com> wrote:
> On 4/10/25 5:59 AM, Andre Vehreschild wrote:
> > Hi all,
> >
> > I again have a series of patches. This time to improve the teams support in
> > gfortran.
> >
> > 1/5: Improves/Unifies handling of STAT= and ERRMSG= handling, which is part
> > of all TEAM statements. I wanted to prevent repeating myself over and over
> > so I factored this out (DRY principle). Because the standard's rule name
> > for this is sync_stat the structure to store the information in gfc_code is
> > named like that.
> >
> > 2/5: Rework (FORM|CHANGE|END|SYNC) TEAM and CRITICAL to use sync_stat and
> > adhere to F2018 standard as much as possible. Because CHANGE TEAM has kind
> > of an association list (but for coarrays only), I choose to factor out that
> > parsing and other preparations from ASSOCIATE. Added support to caf_single
> > for testing.
> >
> > 3/5: Update/Implement get_team()/team_number() and image_status() parsing
> > and also add testcases as well as support in caf_single.
> >
> > 4/5: Update this_image() parsing and treatment as well as adding testcases
> > and support in caf_single.
> >
> > 5/5: Update image_index() and num_images() support also in caf_single.
> >
> > All patches together have been bootstrapped and regtested ok on
> > x86_64-pc-linux-gnu.
> >
> > Regards,
> > Andre
> > --
> > Andre Vehreschild * Email: vehre ad gmx dot de
>
> I have reviewed the five patches and have the following nits shown
> below. These are simply white space fixes.
>
> I had a couple of reject hunks in intrinsics.texi when applying the
> patches.
>
> All applies cleanly and regression tests here as well.
>
> It looks OK to commit.
>
> Regards,
>
> Jerry
>
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -11467,12 +11467,11 @@ resolve_scalar_variable_as_arg (const char
> *name, bt exp_type, int exp_kind,
> gfc_expr *e)
> {
> gfc_resolve_expr (e);
> if (e
> && (e->ts.type != exp_type || e->ts.kind < exp_kind || e->rank != 0
> || e->expr_type != EXPR_VARIABLE))
> gfc_error (
> "%s argument at %L must be a scalar %s variable of at least kind %d",
> name, &e->where, gfc_basic_typename (exp_type), exp_kind);
>
> @@ -11685,8 +11684,7 @@ resolve_branch (gfc_st_label *label, gfc_code *code)
>
> if (code->here == label)
> {
> gfc_warning (0,
> "Branch at %L may result in an infinite loop", &code->loc);
> return;
> }
>
> @@ -11753,8 +11751,7 @@ resolve_branch (gfc_st_label *label, gfc_code *code)
> allowed in Fortran 66, so we allow it as extension. No
> further checks are necessary in this case. */
> gfc_notify_std (GFC_STD_LEGACY, "Label at %L is not in the same block "
> "as the GOTO statement at %L", &label->where, &code->loc);
>
--
Andre Vehreschild * Email: vehre ad gmx dot de
