[Bug fortran/102973] New: possible inconsistency in procptr_assignment handling when matching ASSOCIATE

[Bug fortran/102973] New: possible inconsistency in procptr_assignment handling when matching ASSOCIATE

[aldot at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102973

            Bug ID: 102973
           Summary: possible inconsistency in procptr_assignment handling
                    when matching ASSOCIATE
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: aldot at gcc dot gnu.org
  Target Milestone: ---

As noted in https://gcc.gnu.org/pipermail/fortran/2018-September/050809.html

i spotted one
(pre-existing) possible inconsistency that i did overlook back then:

gfc_match_associate () reads
...
      if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
        {
          /* Have another go, allowing for procedure pointer selectors.  */
          gfc_matching_procptr_assignment = 1;
          if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
            {
              gfc_error ("Invalid association target at %C");
              goto assocListError;
            }
          gfc_matching_procptr_assignment = 0;
        }

i.e. we retry a match, but in the second attempt we turn on procptr
assignment matching and if that works, we turn procptr assignment
matching off again.
But if we fail that retry, we forget to turn it off again.
I suppose we should:

$ svn diff -x -p gcc/fortran/match.c
Index: gcc/fortran/match.c
===================================================================
--- gcc/fortran/match.c (revision 264040)
+++ gcc/fortran/match.c (working copy)
@@ -1898,13 +1898,16 @@ gfc_match_associate (void)
       if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
  {
    /* Have another go, allowing for procedure pointer selectors.  */
+   match m;
+
    gfc_matching_procptr_assignment = 1;
-   if (gfc_match (" %e", &newAssoc->target) != MATCH_YES)
+   m = gfc_match (" %e", &newAssoc->target);
+   gfc_matching_procptr_assignment = 0;
+   if (m != MATCH_YES)
      {
        gfc_error ("Invalid association target at %C");
        goto assocListError;
      }
-   gfc_matching_procptr_assignment = 0;
  }
       newAssoc->where = gfc_current_locus;


Untested. Maybe someone wants to give it a whirl...
If it wrecks havoc then leaving it set deliberately deserves at least a
comment.

PS: It would be nice to get rid of gfc_matching_procptr_assignment,
gfc_matching_ptr_assignment, gfc_matching_prefix, FWIW.

[Bug fortran/102973] possible inconsistency in procptr_assignment handling when matching ASSOCIATE

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102973

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-10-28
                 CC|                            |anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
The analysis seems correct.  The adusted logic would also agree with similar
code in gfc_match_pointer_assignment ().

I did play a little with ASSOCIATE to see if I could trigger a bug in mainline
due to running into a wrong gfc_matching_procptr_assignment, but didn't
succeed.

If you provide a patch for the above that regtests ok, it is pre-approved.

It is not clear to me how to get rid of gfc_matching_procptr_assignment
completely and easily.  One would need to inspect gfc_match_varspec ()
and gfc_match_rvalue () and their callers.  I'd recomment to defer that.

[Bug fortran/102973] possible inconsistency in procptr_assignment handling when matching ASSOCIATE

[pault at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102973

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi All,

Following comment #1 there does not seem to have been a testcase provided that
would require the fix nor has anybody shown that it does or does not wreck
havoc.

I am changing it to waiting.

Cheers

Paul