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.
