From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id E1622384B112; Tue, 23 Apr 2024 15:18:46 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E1622384B112
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1713885526;
	bh=fyZnTXC/NcrapS8E0foUXZPR+FqpbCLL3FIV3qIa/ZI=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=hH/RY2wgzvu6zNJ4XmwUnyBrcTAWwEWb9B3pAK8tGj/zv6bpuiGTF1TUenMD96EH5
	 efIUfQs4HCpqelkRXZkg4WgjPX3f6j6tYG4EdQEWK8Y8qM/0OalzxuL4D8hzqWnBUP
	 Ooe/eWB70c0vUamLMfeVbgREBgkontKCjP7c7h20=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/114825] [11/12/13/14 Regression] Compiler error using
 gfortran and OpenMP since r5-1190
Date: Tue, 23 Apr 2024 15:18:45 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: ice-on-valid-code, openmp
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.5
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-114825-4-Gq07jMKVHk@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-114825-4@http.gcc.gnu.org/bugzilla/>
References: <bug-114825-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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 =3D> b(1)
  !$omp end parallel
contains
  subroutine sub
!    d =3D> 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 =
=3D>
b(1)
commented out is a VAR_DECL created by tree-nested.cc:
#5  0x000000000123a64b in build_decl (loc=3D21312, code=3DVAR_DECL,
name=3D<identifier_node 0x7fffe9efc118 d>, type=3D<pointer_type 0x7fffe9f03=
150>) at
../../gcc/tree.cc:5379
#6  0x0000000000f4f39e in get_local_debug_decl (info=3D0x3b871d0, decl=3D<v=
ar_decl
0x7fffea137c60 d>, field=3D<field_decl 0x7fffe9f00720 d>) at
../../gcc/tree-nested.cc:1895
#7  0x0000000000f504c9 in convert_local_omp_clauses (pclauses=3D0x7fffea134=
780,
wi=3D0x7fffffffd9b0) at ../../gcc/tree-nested.cc:2157

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