Re: [Patch,Fortran] PR41582 allocate patch for CLASS

[Janus Weil <janus at gcc dot gnu dot org>]

Hi Tobias,

thanks for your patch. Looks good to me. Just one remark ...

> a) A constraint for ALLOCATE (class with abstract base type):
> "C625 (R623) If any allocate-object is unlimited polymorphic or
> ?is of abstract type, either type-spec or SOURCE= shall appear."

When checking for the 'abstract' attribute in resolve_allocate_expr,
one has to determine the attributes of the given expression. Couldn't
this be done via 'gfc_expr_attr' or 'gfc_variable_attr', or is there
something special about it? Similar things happen also in
resolve_deallocate_expr, and it looks quite kludgy ...


> (If you miss "abstract type" in your copy of the standard, you
> ?do not have read Corrigendum 1.)

Ah, I was wondering why I couldn't find it ...


> b) Reject "allocate(..., SOURCE=<class>)". To make it work, one
> needs to know the size at run time, which does not work yet. I
> think it makes sense to reject it rather than to use the size of
> the base type and only to warn about it.

Right. It's better to reject it completely as long as it is not
implemented. The question is if we cannot implement it before the 4.5
release. Let's see what options we have (without a vtable):

1) Use a SWITCH block like Paul does for TBPs. This works but is not
very elegant IMHO.

2) Add a 'size' field to the class container. Advantage: Cleaner code,
better performance. Downside: Larger class container. (Ideally this
field could be in the vtable, so that it does not need to be stored
for each class variable, but only once.)

3) Determine the allocated size of the class variable at runtime, e.g.
via glibc's malloc_usable_size. Problem: Portability? Would this
option be viable at all?

Anything I missed? If we can agree on an option, I can try to
implement it. I guess a vtable is not gonna happen for 4.5?

Cheers,
Janus