Hi Harald,
On 22.07.21 21:03, Harald Anlauf wrote:
you are right in that I was barking up the wrong tree.
I was focussed too much on the testcase in the PR.
[...]
Well, I tried and this does not work.
Which makes sense if one thinks about it:
When using 'a(5,:)', the parser already sets e->rank = 1.
while for 'a', the 'a' is the class wrapper with rank == 0 and
then overriding the e->rank by CLASS_DATA(e)->as.rank
+ adding AR_FULL makes sense.
However, an additional plain check on e->rank != 0 also in the
CLASS cases fixes the original issue as well as your example:
[...]
And regtests ok. :-)
See attached updated patch.
I think you still need to remove the 'return true;' from
the 'if (e->rank != 0 && e->ts.type == BT_CLASS' block – to
fall through to the e->rank check after the block.
(When 'return true;' is gone, the '{' and '}' can also be removed.)
Reason: Assume 'CLASS(...) x'. In this case, 'x' is a scalar.
And even after calling gfc_add_class_array_ref it remains
a scalar and e->rank == 0.
Or in other words: I think with your current patch,
class(u) :: z
f = size (z)
is wrongly accepted without an error.
Thus: OK with a scalar CLASS entry added which gives an error,
which I believe requires the removal of the 'return true;' line.
Thanks for the patch – and I find it surprising how many
combinations exist which all can go wrong.
Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
