https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116733

--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> ---
Working through J3/24-136r1 by Malcolm Cohen

Subject: DIN-4: Generic processing of assumed-rank objects
Date: 2024-June-24

1. Introduction

"DIN-4 suggests
    "Allow generic processing of assumed-rank arguments,
     possibly under suitable restrictions."

That is a very vague requirement.
This paper suggests some concrete possibilities. ...snip.."

***Agreed.***

2. Assumed size
I selected:
"    (3) Raise a runtime error if the "generic processing" is applied to an
        assumed-size array. This has the advantage of avoiding silent wrong
        answers, but the disadvantage of not (in general) being capable of
        being caught and handled by the user program."

***In the patch, I elected to use a warning, rather than an error.
Additionally,
I chose to add a compile time warning if an assumed size object is passed
directly to an assumed rank dummy.***

3. Contexts for additional usage of assumed rank

3.1 Whole-array reductions

"It would seem to unproblematic to permit assumed rank in array reduction
intrinsics when there is no DIM argument. The result in this case is
reduced all the way to scalar, so there is no nightmare "variable rank"
expression.

ALL, ANY, REDUCE, SUM, PRODUCT, MAXVAL, MINVAL, IALL, IANY,
IPARITY, PARITY.
...snip...
The location reductions MAXLOC, MINLOC, FINDLOC could also be permitted for
assumed rank. The sizes of their results would be non-constant, but the
rank would be constant."

***I have not touced any of these yet but, as Malcolm remarks, the should
be unproblematic.***

3.2 Array constructors

*** This patch does not permit and assumed rank object in an array
constructor, but I see no reason why it should not be implementable. ***

3.3 Array transformation intrinsics

"The only one here that is clearly non-problematic is RESHAPE.
It does not seem very useful by itself."

***This is implemented in the patch.***

3.4 Actual argument for sequence association

This would seem to be unproblematic in all cases. If contiguous, the
processor can just pass the address of the first element, and if non-
contiguous, the processor can do copy-in/copy-out (at the usual cost).

***Agreed but not implemented in the patch.***

3.5 Contiguous assumed rank

"There are additional contexts where a contiguous assumed rank object could
be used, for example, as the target in a rank-remapped pointer assignment.
Because rank-remapping pointer assignment has all the bounds specified, it
would be unproblematic for assumed-size too.

There has also been a suggestion to allow rank-remapping in ASSOCIATE to
enable this to be done. That seems to be unnecessary given we already have
rank remapping for pointers, and there has been no clamour for it in
ASSOCIATE for things that are not assumed-rank."

***Both are implemented in the patch.***

3.6 C_LOC

"C_LOC of an array returns the address of its first element. There would
thus seem to be no problem permitting it for an assumed rank array, though
it would not be of much use unless the array is contiguous."

***Not implemented in the patch.***

3.7 Array elements

***Not implemented in the patch.***

3.8 Array sections with triplets

***Not implemented in the patch.***

3.9 Other array sections

These don't seem reasonably possible without falling foul of the "unknown
rank" issue.

***Agreed***

4. Assumed rank array traversal

Due to the problem of variable-rank expressions, there is no obvious way to
use elemental procedures on assumed-rank objects, even though the compiler
would know how to traverse them.

***Agreed. I have not given consideration to the suggested, possible
solutions. ***

5. Conclusions

"Rank-remapping pointer assignment would seem to be easy and lacking in
problems (even assumed-size).

After that, array reduction intrinsics without DIM= have no problems
other than the assumed-size one, and so would seem to be worth considering.

Although there are even more potential problems, the more general array
element subscripting and array traversal operations are also worth further
consideration."

***Agreed***

Reply via email to