Patch to enable unlimited polymorphism to gfortran

Tobias Burnus burnus@net-b.de
Tue Dec 18 22:33:00 GMT 2012


Paul Richard Thomas wrote:
> Please find attached an updated version of the patch, which I believe
> answers your comments/objections.

Thanks for the patch. They patch is OK from my side, if you address the 
issues below.

> + /* Assign a hash value for an intrinsic type. The algorithm is that of SDBM.  */
> +
> + unsigned int
> + gfc_intrinsic_hash_value (gfc_typespec *ts)
> + {
> +   unsigned int hash = 0;
> +   char c[2*(GFC_MAX_SYMBOL_LEN+1)];
> +   int i, len;
> +
> +   strcpy (&c[0], gfc_typename (ts));

I think you should simply use
    const char *c = gfc_typename (ts);
as you do not modify "c". That saves some memory on the stack and avoids 
a function call. Additionally, it prevents me from wondering why you 
need more than GFC_MAX_SYMBOL_LEN.


> + /* Find (or generate) the symbol for an intrinsic types's vtab.  This is
> +    need to support unlimited polymorphism.  */

types's -> type's


> + 	gfc_error ("Actual argument to '%s' at %L must be unlimited "
> + 		   "polymorphic since the formal argument is %s, "
> + 		   "unlimited polymorphic entity [F2008: 12.5.2.5]",
> + 		   formal->name, &actual->where,
> + 		   CLASS_DATA (formal)->attr.class_pointer ?
> + 		   "a pointer" : "an allocatable");

I fear that translators will hate you for the "%s" with "a pointer" / 
"an allocatable". At least when "a pointer"/"an allocatable" occurs 
elsewhere, they cannot properly translate it as the translation might 
depend whether it is subject or object in the sentence. Even if not, 
translators will not (easily) see that those strings belong to this 
error message.

> + 	  if (UNLIMITED_POLY (tail->expr))
> + 	    gfc_error ("Unlimited polymorphic allocate-object at %L "
> + 		       "requires either a type-spec or SOURCE tag",
> + 		       &tail->expr->where);

That's not true. The standard also allows MOLD=. Thus, either add "or 
MOLD" or change "SOURCE tag" to "source-expr(ession)", which covers both.

I haven't checked the source code, but you might have to add an "&& 
!mold" as well.


Tobias



More information about the Gcc-patches mailing list