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