[Bug fortran/107406] New: lock_type

[Bug fortran/107406] New: lock_type

[damian at archaeologic dot codes]

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

            Bug ID: 107406
           Summary: lock_type
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: damian at archaeologic dot codes
  Target Milestone: ---

gfortran 12.2 accepts the code below if the "allocatable" attribute is removed:

% cat gfortran-lock-issue.f90 
  use iso_fortran_env
  type foo
    type(lock_type), allocatable :: bar
  end type
  type(foo) foobar[*]
end

% gfortran -fcoarray=single gfortran-lock-issue.f90 
gfortran-lock-issue.f90:3:39:

    3 |     type(lock_type), allocatable :: bar
      |                                       1
Error: Allocatable component bar at (1) of type LOCK_TYPE must have a
codimension

The NAG compiler accepts the above code and I believe constraint C1608 in the
Fortran 2018 standard makes the above code valid.

Is this related to PR 92122?

[Bug fortran/107406] lock_type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-10-27
           Priority|P3                          |P4
                 CC|                            |kargl at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Damian Rouson from comment #0)
> gfortran 12.2 accepts the code below if the "allocatable" attribute is
> removed:
> 
> % cat gfortran-lock-issue.f90 
>   use iso_fortran_env
>   type foo
>     type(lock_type), allocatable :: bar
>   end type
>   type(foo) foobar[*]
> end
> 
> % gfortran -fcoarray=single gfortran-lock-issue.f90 
> gfortran-lock-issue.f90:3:39:
> 
>     3 |     type(lock_type), allocatable :: bar
>       |                                       1
> Error: Allocatable component bar at (1) of type LOCK_TYPE must have a
> codimension
> 
> The NAG compiler accepts the above code and I believe constraint C1608 in
> the Fortran 2018 standard makes the above code valid.
> 
> Is this related to PR 92122?

Yes, it is likely related.

The code that gives rise to the error is trying to check F2008:C1302.

    C1302 A named variable of type LOCK_TYPE shall be a coarray.
    A named variable with a noncoarray sub-component of type
    LOCK_TYPE shall be a coarray.

I think the 2nd sentence has been misinterpreted.  The named variable is foobar
and it is a coarray.  bar is a component of derived type and is not a named
variable.  In the parlance of Fortran, bar is a subobject and is referred to as
an object designator.

The same applies to PR92122.

The following patch allows your example to compile with 'gfortran
-fcoarray=single a.f90'.

diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index f04fd13cc69..8440f58ef23 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -3339,7 +3339,7 @@ check_component (gfc_symbol *sym, gfc_component *c,
gfc_component **lockp,
                "of type LOCK_TYPE, which must have a codimension or be a "
                "subcomponent of a coarray", c->name, &c->loc);

-  if (lock_type && allocatable && !coarray)
+  if (lock_type && allocatable && !coarray && !lock_comp)
     gfc_error ("Allocatable component %s at %L of type LOCK_TYPE must have "
                "a codimension", c->name, &c->loc);
   else if (lock_type && allocatable && c->ts.type == BT_DERIVED

Note, the section of code is prefaced with the following comment

  /* Check for F2008, C1302 - and recall that pointers may not be coarrays
     (5.3.14) and that subobjects of coarray are coarray themselves (2.4.7),
     unless there are nondirect [allocatable or pointer] components
     involved (cf. 1.3.33.1 and 1.3.33.3).  */

Someone who knows coarrays needs to verify the veracity of the comment.