Re: Patch to enable unlimited polymorphism to gfortran

[Paul Richard Thomas <paul dot richard dot thomas at gmail dot com>]

Dear Tobias,

Up front, thanks for this initial feedback.  Dominique informed me on
#gfortran that "the patch works as advertised".

...snip...
> Running your test cases through crayftn, I found:
>
>   if (SAME_TYPE_AS (obj1, u1) .neqv. .FALSE.) call abort
>                           ^
> ftn-1698 crayftn: ERROR $MAIN, File = unlimited_polymorphic_1.f03, Line =
> 67, Column = 27
> Type INTEGER(kind=4) is not allowed for the "B" argument of intrinsic
> SAME_TYPE_AS.
...snip...
> At least for -std=f2003/f2008 we have to reject nonextensible,
> non-unlimited-polymorphic arguments. - Even if a supporting intrinsic types
> were a nice addition.

gfortran was already giving an error at the right place - see
same_type_as_1.f03  I have improved the message to contain the name of
the offending type, like the Cray compiler.  I believe the Cray
compiler has a bug at this point.
>.
..snip...
>
> You have a " " at both then end and the beginning of the line. Additionally,

Indeed - thanks

...snip...

> "F2008"). Thus, I'd use something like:
>
> +         gfc_error ("Array constructor value at %L shall not be unlimited"
> +                    " polymorphic [Fortran 2008, C4106]", &c->expr->where);
>
>

That's fine by me. I have changed all the messages, as suggested.
However, F03/08 is so widespread in comments that I have left well
alone.


> (Off-topic question for mere curiosity: Why "$tar"?)

Well '$' is non-alphanumeric but is just an 's' with a bar through it :-)


> The same issue also applies to assumed-length strings. At least the
> following program prints:
>            0 ""
>            0 ""

Adding an error to pick up assumed length is proving to be problematic
because the TYPE IS selector is assumed length.  I'll think about it
some  more.

> I think we have to fill a PR which lists all of the known deficits of the
> current implementation. Besides the string issue, that's also the renaming
> of gfc_find_intrinsic_vtab into gfc_find_derived_vtab.

I did not do this immediately because the latter takes the derived
type, whilst the former uses the typespec. When the two are rolled
into one function, the typespec will be used.

I agree that a catch-all PR is needed for class(*) limitations.

...snip...

>
>
>> + #define UNLIMITED_POLY(sym) (sym != NULL && sym->ts.type == BT_CLASS &&
>> CLASS_DATA (sym) \
>> +                       && CLASS_DATA (sym)->ts.u.derived \
>> +                       && CLASS_DATA
>> (sym)->ts.u.derived->attr.unlimited_polymorphic)
>
>
> The lines are way too long: 90 and 86 characters.

Blush - yes, you are right. Done.

>
>
>> +   sprintf (name, "__tmp_%s_%d", gfc_basic_typename (ts->type),
>> +          ts->type == BT_CHARACTER ? charlen : ts->kind);
>
>
> How do you distinguish between character(kind=1) and character(kind=4)? The
> same issue exists for a like-wise code in resolve_select_type.

I have introduced that distinction seemingly without anything breaking!
TYPE IS (CHARACTER(*, kind = 4) works fine.

>
>
> +  /* Unlimited polymorphic pointers should have their vptr nullified.  */
> +  if (UNLIMITED_POLY (sym) && CLASS_DATA (sym)->attr.pointer)
> +    gfc_defer_symbol_init (sym);
>
>
> Why? If the pointer has never been pointer-associated, one shouldn't access

It's so that SAME_TYPE_AS and EXTENDS_TYPE_OF do the right thing with
unassociated pointers.  I am not sure that I understand your concern
if the code is needed.

Cheers

Paul