This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Patch to enable unlimited polymorphism to gfortran
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