*PING*
I think the patch is an improvement, even though there is a small
regression and many issues are not covered: PR fortran/99266 and as
explained below.
On 25.02.21 12:16, Tobias Burnus wrote:
The issue is that for CLASS – and in particular CLASS(*)
the ts.u.derived->components is not yet created when it is
accessed. – PR99138 shows a similar case (unfixed!
See comment 5 and initial report for two examples).
There is an issue for code like:
class(*) var
dimension :: var(..)
that the attribute is not properly encoded in the class.
That's independent of this patch, cf. PR fortran/99266.
NOTE: This patch causes a regression:
subroutine foo()
class(*) :: x
allocatable :: x
is now rejected with:
CLASS variable ‘x’ at (1) must be dummy, allocatable or pointer
HOWEVER: While that was accepted before,
subroutine foo(dummy)
class(*) :: dummy
allocatable :: dummy
failed before and still fails. (→ class_ok handling in
gfc_build_class_symbol).
All those issues are tracked in that PR fortran/99266.
OK for the trunk? What about GCC 10??
I am unsure about GCC 10 due to the new regression;
the issue (PR99254) was reported as new ICE between
20190825 and 20190901.
Tobias
PS: I still do not like the way we represent CLASS internally,
but I think I had complained about this already years ago...
Can proponents of the current way please look at
PR fortran/99266 ?
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 München
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Frank
Thürauf
