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.
