[Bug libgomp/114825] New: Compiler error using gfortran and OpenMP

[Bug libgomp/114825] New: Compiler error using gfortran and OpenMP

[marcos.vanella at nist dot gov]

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

            Bug ID: 114825
           Summary: Compiler error using gfortran and OpenMP
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marcos.vanella at nist dot gov
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 58016
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58016&action=edit
Fortran Module source to reproduce described error.

Hi we have found a compiler error when compiling a fortran module with
gfortran.
In the following minimal reproducing code snippet, the module DIVG contains
some derived types (BOUNDARY_PROP1_TYPE,WALL_TYPE), a contained subroutine
called DIVERGENCE_PART_1 which also contains a subroutine called
ENTHALPY_ADVECTION.

In DIVERGENCE_PART_1 there is a WALL_LOOP that has an !$OMP PARALLEL construct
with three PRIVATE variables IW (counter), WC (a pointer to an array WALL of
type WALL_TYPE) and B1 (a pointer to an array BOUNDARY_PROP1 of type
BOUNDARY_PROP1_TYPE). 
A WALL_LOOP_2 loop is also used in the contained routine ENTHALPY_ADVECTION
called at the end of DIVERGENCE_PART_1. This loop does the same tasks as the
previous and is not instrumented with OpenMP.

Compiling the divg.f90 file with GCC 11.4 or 13.2 in both Pop-OS Linux and Mac
OSX 14 gives the following error:

$ gfortran -c -save-temps -freport-bug -m64 -O0 -std=f2018 -ggdb -Wall
-Wcharacter-truncation -Wno-target-lifetime -fcheck=all -fbacktrace
-ffpe-trap=invalid,zero,overflow -frecursive -ffpe-summary=none
-fall-intrinsics -cpp -fopenmp divg.f90
during GIMPLE pass: omplower
divg.f90:44:52:

   44 | !$OMP PARALLEL DO PRIVATE(IW,WC,B1) SCHEDULE(GUIDED)
      |                                                    ^
internal compiler error: in gfc_omp_clause_default_ctor, at
fortran/trans-openmp.cc:746
Please submit a full bug report, with preprocessed source.
See <https://github.com/Homebrew/homebrew-core/issues> for instructions.

If we comment the ALLOCATABLE field ZZ_G in the derived type
BOUNDARY_PROP1_TYPE the module compiles without error.

Thank you for your time and attention.
Marcos

[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-04-23
           Priority|P3                          |P2
          Component|libgomp                     |fortran
     Ever confirmed|0                           |1
   Target Milestone|---                         |11.5
                 CC|                            |burnus at gcc dot gnu.org
            Summary|Compiler error using        |[11/12/13/14 Regression]
                   |gfortran and OpenMP         |Compiler error using
                   |                            |gfortran and OpenMP since
                   |                            |r5-1190

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r5-1190-g92d28cbb59cc5a611af41342c5b224fbf779a44d
Reduced testcase (just -fopenmp needed):
subroutine pr114825(b)
  type t
    real, allocatable :: m(:)
  end type t
  type(t), allocatable, target :: b(:)
  type(t), pointer :: d
  !$omp parallel private(d)
  d => b(1)
  !$omp end parallel
contains
  subroutine sub
    d => b(1)
  end subroutine sub
end subroutine pr114825

[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
The difference between the failing program and a working program
(pointer-assignment in 'sub' comment out) is:

failing:
  'type' in gfc_omp_clause_default_ctor is '<record_type 0x7ffff7004930 t'

working:
  'type' is '<pointer_type 0x7ffff700a150 ... <record_type 0x7ffff7004930 t'

(and 'outer' is NULL in either case)

In the caller, i.e. lower_rec_input_clauses:
  working:
    p debug_tree(new_var) → <var_decl 0x7ffff720df30 d
  failing:
    p debug(new_var) → *d – i.e. with a memory dereference.

The reason is that gfc_omp_privatize_by_reference returns true in the
omp-low.cc's lower_rec_input_clauses call to it:

5737              else if (omp_privatize_by_reference (var)
5738                       && (c_kind != OMP_CLAUSE_FIRSTPRIVATE
5739                           || !OMP_CLAUSE_FIRSTPRIVATE_NO_REFERENCE (c)))



The problem is that:
      /* Array POINTER/ALLOCATABLE have aggregate types, all user variables
         that have POINTER_TYPE type and aren't scalar pointers, scalar
         allocatables, Cray pointees or C pointers are supposed to be
         privatized by reference.  */
      if (GFC_DECL_GET_SCALAR_POINTER (decl)
          || GFC_DECL_GET_SCALAR_ALLOCATABLE (decl)
          || GFC_DECL_CRAY_POINTEE (decl)
          || GFC_DECL_ASSOCIATE_VAR_P (decl)
          || VOID_TYPE_P (TREE_TYPE (TREE_TYPE (decl))))
        return false;
fails in the failing case – but works in the non-failing case – IHMO, it should
have matched the first item.

[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Yes, and the reason for that is that while in
subroutine pr114825(b)
  type t
    real, allocatable :: m(:)
  end type t
  type(t), allocatable, target :: b(:)
  type(t), pointer :: d
  !$omp parallel private(d)
  d => b(1)
  !$omp end parallel
contains
  subroutine sub
!    d => b(1)
  end subroutine sub
end subroutine pr114825

the d in the private clause is the VAR_DECL created by the Fortran FE with
DECL_LANG_SPECIFIC, d in the private clause in the testcase without the d =>
b(1)
commented out is a VAR_DECL created by tree-nested.cc:
#5  0x000000000123a64b in build_decl (loc=21312, code=VAR_DECL,
name=<identifier_node 0x7fffe9efc118 d>, type=<pointer_type 0x7fffe9f03150>) at
../../gcc/tree.cc:5379
#6  0x0000000000f4f39e in get_local_debug_decl (info=0x3b871d0, decl=<var_decl
0x7fffea137c60 d>, field=<field_decl 0x7fffe9f00720 d>) at
../../gcc/tree-nested.cc:1895
#7  0x0000000000f504c9 in convert_local_omp_clauses (pclauses=0x7fffea134780,
wi=0x7fffffffd9b0) at ../../gcc/tree-nested.cc:2157

Perhaps get_local_debug_decl should also copy DECL_LANG_SPECIFIC?  Of course,
perhaps it might need e.g. DECL_LANG_FLAG_* too.  If decl in there is just a
VAR_DECL, we might 
as well just copy_node it and tweak afterwards, but if it is e.g. a PARM_DECL,
that wouldn't be possible.

[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 58027
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58027&action=edit
gcc14-pr114825.patch

Untested fix.

[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:14d48516e588ad2b35e2007b3970bdcb1b3f145c

commit r14-10130-g14d48516e588ad2b35e2007b3970bdcb1b3f145c
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Apr 25 20:09:35 2024 +0200

    openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl
copy [PR114825]

    tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used
    both for debug info and OpenMP/OpenACC lowering purposes, the other solely
for
    OpenMP/OpenACC lowering purposes.
    When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks
(mostly
    Fortran, C just a little and C++ doesn't have nested functions) then
inspect
    the flags on the vars and based on that decide how to lower the
corresponding
    clauses.

    Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?,
so
    the langhooks made decisions on the default flags on those instead.
    As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL,
    using copy_node wouldn't work properly, so this patch just copies those
    flags in addition to other flags it was copying already.  And I've removed
    code duplication by introducing a helper function which does copying common
    to both uses.

    2024-04-25  Jakub Jelinek  <jakub@redhat.com>

            PR fortran/114825
            * tree-nested.cc (get_debug_decl): New function.
            (get_nonlocal_debug_decl): Use it.
            (get_local_debug_decl): Likewise.

            * gfortran.dg/gomp/pr114825.f90: New test.

[Bug fortran/114825] [11/12/13 Regression] Compiler error using gfortran and OpenMP since r5-1190

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13/14 Regression]    |[11/12/13 Regression]
                   |Compiler error using        |Compiler error using
                   |gfortran and OpenMP since   |gfortran and OpenMP since
                   |r5-1190                     |r5-1190

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk so far.