http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50959
--- Comment #1 from janus at gcc dot gnu.org 2011-11-02 11:28:51 UTC --- (In reply to comment #0) > It is pointless to store the vptr if one does not use it. The problem is: How do we know if it will be used later on or not? > Example: The invalid ("x" is not allocated) code > use m > class(t), allocatable :: x > j = x%i > produces the dump: > x._data = 0B; > (struct __vtype_m_T *) x._vptr = &__vtab_m_T; > j = x._data->i; > > There is no point for the "x._vptr = ". The vptr for pointers/allocatable > should only be set for ALLOCATE (explicit or polymorphic intrinsic) or pointer > assignment - but not as part of the initialization. well, there is a reason for setting the vptr as part of the initialization: It seems to be valid to call intrinsics like e.g. STORAGE_SIZE or EXTENDS_TYPE_OF also on unallocated polymorphics (cf. PR47024, PR47180, PR47189, PR47194). I think the standard says somewhere that the dynamic type of unallocated/unassociated polymorphic variables equals the declared type (which is why we set the vptr at initialization). > For a more real-world example, see below. There one has: > > (struct __vtype_m_T *) x._vptr = &__vtab_m_T; > /* malloc block */ > (struct __vtype_m_T *) x._vptr = &__vtab_m_T; > where the last line is part of the ALLOCATE. I don't see a good way of dealing with this, except for hoping that the middle-end will optimize away such redundant assignments.