Consider eliminating `type(*)` in the collective subroutines

[rouson]

Fortran 2023 18.3.7 item 7 in the list on page 515 prohibits assumed-type, assumed-rank arguments without the value attribute.

[everythingfunctional]

Based on reading of the standard, it looks like the path forward here has to do with separate procedures for different types, and to use select rank internally to dispatch to different bind(c) procedures. There's still work to do in figuring out exactly what that looks like, and is probably worth some conversations with some other committee members as well.

[bonachea]

Some of my notes from today's meeting:

• Probably need to bifurcate prif_co_{min,max} into _numeric and _character variants
• a argument to _numeric can probably remain contiguous type(*)
• a argument to _character is probably contiguous character with assumed-length
• For ALL prif_co_*: internally we may need to use select rank to handle the assumed-rank at the Fortran level before hitting C
  • Which means we need 16 versions of each BIND(C) caf_ call, one for each possible rank
• POST-CALL question:
  • can we just leverage the TARGET attribute and call C_LOC on the contiguous assumed-rank dummy arg to bypass the select rank mess?

[everythingfunctional]

Taking a fresh look at this, I don't think it's a problem.

A Fortran procedure interface is interoperable with a C function prototype if
...
(5) any dummy argument without the VALUE attribute corresponds to a formal parameter of the prototype that is of a pointer type, and
...

• the dummy argument is ... assumed-rank ..., and the formal parameter is a pointer to CFI_cdesc_t

That doesn't say that the dummy argument can't be assumed-type.

C716 An assumed-type actual argument that corresponds to an assumed-rank dummy argument shall be assumed-shape or assumed-rank.

That certainly implies that assumed-type dummy arguments can be assumed-rank.

If flang seems to have a problem with this, we should file a bug report.