Hello,

Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
-  if (attr->class_ok)
-    /* Class container has already been built.  */
+  /* Class container has already been built with same name.  */
+  if (attr->class_ok
+      && ts->u.derived->components->attr.dimension >= attr->dimension
+      && ts->u.derived->components->attr.codimension >= attr->codimension
+      && ts->u.derived->components->attr.class_pointer >= attr->pointer
+      && ts->u.derived->components->attr.allocatable >= attr->allocatable)

I suppose I'm a bit confused here.  dimension, codimension,
pointer and allocatable are 1-bit bitfields in the attr
struct.  These can have the values 0 and 1, so the above
conditionals are always true.

as I understand it, they aren't if attr has attributes that aren't already set in the class container's first component.
a >= b == !(a < b) and if a and b are boolean-valued, a < b == !a && b.
Admittedly, I haven't tested the logic like Harald has.

The rest of the patch looks reasonable.  If Tobias has no
objections or comments, it's ok to commit once the above
is explained.


I have two comments, one about the handling of as and sym->as, which I quite don't understand, but I haven't had time to write something about it.
The other is about this:
+  else if (sym->ts.type == BT_CLASS
+          && sym->ts.u.derived->attr.is_class
+          && sym->old_symbol && sym->old_symbol->as == CLASS_DATA (sym)->as)
+    sym->old_symbol->as = NULL;
Can this be avoided? The management of symbol versions should not need any manual change. In principle, either the modified symbols are committed, or (in case of error) the previous symbols are restored, but there shouldn't be any need for restoring a modified previous symbol.

I guess it's a matter of memory management, because gfc_build_class_symbol copies the AS pointer to the class descriptor, but I think using gfc_copy_array_spec there or adding the condition above to free_old_symbol would be preferable.

Reply via email to