[Bug fortran/67311] New: ICE calling subroutine with derived type as argument within OpenMP parallel region

[Bug fortran/67311] New: ICE calling subroutine with derived type as argument within OpenMP parallel region

[acreman at astro dot ex.ac.uk]

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

            Bug ID: 67311
           Summary: ICE calling subroutine with derived type as argument
                    within OpenMP parallel region
           Product: gcc
           Version: 5.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acreman at astro dot ex.ac.uk
  Target Milestone: ---

The following test case produces an internal compiler error with recent
gfortran versions:

! == Begin test case ==
subroutine test
  call openmp_sub
end subroutine test

subroutine openmp_sub

  implicit none

  TYPE myType
    TYPE(myType), DIMENSION(:), POINTER :: x
  END TYPE myType

  type(myType) :: argument
!$OMP PARALLEL DEFAULT(NONE) PRIVATE(argument)
  call foo(argument)
!$OMP END PARALLEL

end subroutine openmp_sub
! == End test case ==

The command line used to build was:  gfortran -c -fopenmp test.f90
I see an ICE at versions 4.9.3 and 5.2 on SLES and gfortran 4.9.2 on Mac OS. 
The test case compiles OK with version 4.6.3 (SLES) and 4.8.2 (Ubuntu)

The output from gfortran 4.9.3 is: 

> gfortran -c -fopenmp test.f90
gfortran: internal compiler error: Segmentation fault (program f951)
0x40d14c execute
        ../../gcc-4.9.3/gcc/gcc.c:2854
0x40d514 do_spec_1
        ../../gcc-4.9.3/gcc/gcc.c:4658
0x40fdd6 process_brace_body
        ../../gcc-4.9.3/gcc/gcc.c:5941
0x40fdd6 handle_braces
        ../../gcc-4.9.3/gcc/gcc.c:5855
0x40e389 do_spec_1
        ../../gcc-4.9.3/gcc/gcc.c:5312
0x40fdd6 process_brace_body
        ../../gcc-4.9.3/gcc/gcc.c:5941
0x40fdd6 handle_braces
        ../../gcc-4.9.3/gcc/gcc.c:5855
0x40e389 do_spec_1
        ../../gcc-4.9.3/gcc/gcc.c:5312
0x40e0f3 do_spec_1
        ../../gcc-4.9.3/gcc/gcc.c:5427
0x40fdd6 process_brace_body
        ../../gcc-4.9.3/gcc/gcc.c:5941
0x40fdd6 handle_braces
        ../../gcc-4.9.3/gcc/gcc.c:5855
0x40e389 do_spec_1
        ../../gcc-4.9.3/gcc/gcc.c:5312
0x40fdd6 process_brace_body
        ../../gcc-4.9.3/gcc/gcc.c:5941
0x40fdd6 handle_braces
        ../../gcc-4.9.3/gcc/gcc.c:5855
0x40e389 do_spec_1
        ../../gcc-4.9.3/gcc/gcc.c:5312
0x40eea6 do_spec_2
        ../../gcc-4.9.3/gcc/gcc.c:4359
0x4104b8 do_spec(char const*)
        ../../gcc-4.9.3/gcc/gcc.c:4326
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-08-21
                 CC|                            |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The ICE appeared between revisions r211105 (2014-05-31, no ICE) and r211652
(2014-06-13, ICE) for 5.0. The change has been back ported to 4.9.

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |openmp
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ugh, Fortran really allows this mess (effectively self-referential types)?  The
infinite recursion in gfc_has_alloc_comps supposedly can be dealt with by
adding say a pointer set of seen types and returning 0 for them rather than
recursing on them, or something similar.
But if the type has allocatable components, is there anything that would
prevent the need for endless recursion when actually generating code to expand
it?
Or is here only POINTER allowed and not ALLOCATABLE?
  TYPE myType
    TYPE(myType), DIMENSION(:), ALLOCATABLE :: x
  END TYPE myType

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Ugh, Fortran really allows this mess (effectively self-referential types)? 
I believe it does:

C440 (R436) If neither the POINTER nor the ALLOCATABLE attribute is specified,
the declaration-type-spec
in the component-def-stmt shall specify an intrinsic type or a previously
defined derived type.

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Seems with ALLOCATABLE rather than POINTER it is rejected though:
  TYPE myType
    TYPE(myType), DIMENSION(:), ALLOCATABLE :: x
  END TYPE myType
end
pr67311-2.f90:2:46:

     TYPE(myType), DIMENSION(:), ALLOCATABLE :: x
                                              1
Error: Derived type at (1) has not been previously defined and so cannot appear
in a derived type definition

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Ugh, Fortran really allows this mess (effectively self-referential types)?

It has to - otherwise how to you implement linked lists?

However, I don't know what this is supposed to do in the context of OpenMP. For
coarrays, pointer components are ignored in the context of copying them to
other processes ("images") only directly accessing their values is permitted.
If OpenMP works likewise, I'd expect that only the nonpointer components are
created as private object and that the status of the pointer components is
undefined.

> But if the type has allocatable components, is there anything that would
> prevent the need for endless recursion when actually generating code to
> expand it?

> Or is here only POINTER allowed and not ALLOCATABLE?
>   TYPE myType
>     TYPE(myType), DIMENSION(:), ALLOCATABLE :: x
>   END TYPE myType

Fortran 2008 allows allocatable components, which gfortran does not support
(unless I missed an addition in the last few months). However, that requires
explicit action, i.e. you allocate  the component. Then you can access it and
allocate its component etc.
That chain is finite and the innermost one has the allocation status
unallocated (internally, it points to NULL). And as no loops are possible and
no alising within the type, one can simply walk it.

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #4)
> Seems with ALLOCATABLE rather than POINTER it is rejected though:

That's PR45516.

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Patch – without one recursively checks the same type.

--- a/gcc/fortran/trans-openmp.c
+++ b/gcc/fortran/trans-openmp.c
@@ -330,6 +330,11 @@ gfc_has_alloc_comps (tree type, tree decl)
        return false;
     }

+  if (GFC_DESCRIPTOR_TYPE_P (type)
+      && (GFC_TYPE_ARRAY_AKIND (type) == GFC_ARRAY_POINTER
+         || GFC_TYPE_ARRAY_AKIND (type) == GFC_ARRAY_POINTER_CONT))
+    return false;
+
   if (GFC_DESCRIPTOR_TYPE_P (type) || GFC_ARRAY_TYPE_P (type))
     type = gfc_get_element_type (type);

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Submitted patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548920.html

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:174e79bf73331b41b7a14dffd45ed8293487f0e0

commit r11-2078-g174e79bf73331b41b7a14dffd45ed8293487f0e0
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Tue Jul 14 12:55:53 2020 +0200

    [Fortran, OpenMP] Fix allocatable-components check (PR67311)

    gcc/fortran/ChangeLog:

            PR fortran/67311
            * trans-openmp.c (gfc_has_alloc_comps): Return false also for
            pointers to arrays.

    libgomp/ChangeLog:

            PR fortran/67311
            * testsuite/libgomp.fortran/target-map-1.f90: New test.

[Bug fortran/67311] ICE calling subroutine with derived type as argument within OpenMP parallel region

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> ---
FIXED on mainline (GCC 10).

Thanks for the bugreport and sorry for taking nearly 5 years to get it fixed.