https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99819
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 50735
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50735&action=edit
Experimenta "fix" for the PR
The problem lies in class.c(gfc_build_class_symbol).
The attachment contains two different experiments to test the hypothesis that
the array_spec for 'y' is applied to the _data field of the derived type, which
is then promoted to the main namespace. Subsequently, it is picked up in the
declaration of 'z', which cause the problem.
The first chunk, used by itself, turns the array_spec into a deferred array.
The extent information is lost but the testcase now compiles and runs
(incorrectly!). The second chunk, again by itself, puts the derived type
representation in the function namespace. This now runs the testcase correctly
and does the right thing. However, it can only encompass one such dummy.
I'm onto it:-)
Paul
program p
type t
integer :: i
end type
class(t), allocatable :: dum1(:), dum2(:)
allocate (t :: dum1(3), dum2(10))
dum2%i = [1,2,3,4,5,6,7,8,9,10]
print *, f(dum1, dum2), g(dum1)
contains
function g(z)
class(*) :: z(:)
type(t) :: u(size(z))
g = 0
end
function f(x, y)
class(t) :: x(:)
class(*) :: y(size(x))
print *, size(y)
select type (y)
type is (t)
f = 1
if (any (y%i .ne. [1,2,3])) print *, size(y%i)
class default
f = 0
end select
end
end
