Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

[Jerry D]

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);