Re: rfc: multiple decls for functions

[Mikael Morin <mikael dot morin at tele2 dot fr>]

FX wrote:
> 
> I tried what you propose, although in a slightly different way: you can
> find the decls of globally declared functions (which are the ones of
> interest here) by looking at the top binding level (see trans-decl.c and
> f95-lang.c, IIRC). That part of the idea works fine and you can actually
> get the decls you need, but another problem then arises, which I never
> managed to solve (I asked many questions to try and get help in this
> thread: http://gcc.gnu.org/ml/fortran/2008-02/msg00005.html but I never
> managed it; you can use my patch from that message to try and do better
> that I did). The problem is with array arguments: two decls for the same
> function will be different, depending on whether they're built because
> we're translating a function declaration or a function call. That is,
> the decl created for f in:
> 
>     subroutine test(x)
>       integer x(1)
>     end subroutine test
> 
> is different from the one created when translating:
> 
>     integer x(1)
>     call test(x)
> 
> 
> One has GFC_ARRAY_TYPE_P for its argument and the other doesn't. And the
> compiler appears to care: if you reuse the one without GFC_ARRAY_TYPE_P
> when later seeing the subroutine itself, then you trigger an assert.
> I've never understood completely the GFC_ARRAY_TYPE_P madness but all my
> tries to fix this have failed. Which is why I recommended another course
> of action. But you might find a way to coax the arrays to work fine, I'm
> sure there has to be one.
> 
> 
> Good luck,
> FX
> 
Hi all,

I made a bit of progress on this.
I attach my patch, and an update of FX's one.
Arrays are sort of working but there are many regressions.



Here are my investigations. I hope it will be useful to someone.

In trans.h:
>/* An array descriptor.  */
>#define GFC_DESCRIPTOR_TYPE_P(node) TYPE_LANG_FLAG_1(node)
>/* An array without a descriptor.  */
>#define GFC_ARRAY_TYPE_P(node) TYPE_LANG_FLAG_2(node)

So basically GFC_DESCIPTOR_TYPE_P and GFC_ARRAY_TYPE_P are flags
indicating whether there is a descriptor or not.

As GFC_ARRAY_TYPE_P is about descriptorless arrays, gfc_get_nodesc_array
will show how to handle it.
The end of the function is the most interesting:

>  if (packed != PACKED_STATIC || !known_stride)
>    {
>      /* For dummy arrays and automatic (heap allocated) arrays we
>	 want a pointer to the array.  */
>      type = build_pointer_type (type);
>      GFC_ARRAY_TYPE_P (type) = 1;
>      TYPE_LANG_SPECIFIC (type) = TYPE_LANG_SPECIFIC (TREE_TYPE (type));
>    }

A pointer to a GFC_ARRAY_TYPE_P shall also have GFC_ARRAY_TYPE_P set,
and the TYPE_LANG_SPECIFIC shall be the same as the pointee.

This is confirmed by gfc_build_qualified_array, where we have:
>  gcc_assert (GFC_ARRAY_TYPE_P (type));
and later:
>  if (POINTER_TYPE_P (type))

Thus, the GFC_ARRAY_TYPE_P and TYPE_LANG_SPECIFIC attributes from a
pointer shall be copied from the pointee.


That's what needs to be done in gfc_conv_array_parameter.
- If we are interested in descriptorless arrays, the relevant parts are
those where we can see gfc_conv_array_data (the changes I made there are
not much tested), or where we check for un-assumed_shape-ness.
- For arrays with a descriptor, everything happens in
gfc_conv_expr_descriptor. In the se.want_pointer case, the pointer
attributes were not copied from the descriptor. I fixed that.


At that stage, the testcase provided by FX in his previous message was
working. The next problem was with g77 array, which where packed and
passed as a void pointer to the function. The real type was needed to
create function args with the proper types. This was not difficult, as
the array type is present in the GFC_TYPE_ARRAY_DATAPTR_TYPE field of a
GFC_DESCRIPTOR_TYPE_P descriptor.


Now there are still many remaining problematic cases.
For example actual_procedure_1.f90 from the testsuite, where the
external procedure is an actual argument.
I didn't have a look at every regression but many of them happen with a
specific optimization option, which makes them even more difficult to
track.
I'm giving up for now.

Cheers
Mikael

Attachment: fndecl_fx.diff
Description: Text document

Attachment: fndecl_11.diff
Description: Text document