Question about array types in the front-end

[FX Coudert]

I think I may have made some progress... gfc_conv_array_parameter()  
doesn't set GFC_ARRAY_TYPE_P on the tree it returns... Is it normal?  
I don't think so, and with my patch, it yields to the failure because  
the function argument list needs to have it set (it's used later in  
the code path).

So, Paul, anyone? Is it supposed to be that way? If I want   
gfc_conv_array_parameter() to set GFC_ARRAY_TYPE_P on its results,  
where should I do it and on what condition?

Thanks,
FX, new to the array handling


Le 22 févr. 08 à 13:37, FX a écrit :

> Hi all,
>
> I dare ping that question... I'm really stuck with this fndecl issue
> and I think, even though it's probably not so huge a patch, it's
> important for 4.4 and it's also important to commit it early (because
> it's a quite intrusive change). So, if some of you have time to ponder
> on the following... Many thanks in advance!
>
> FX
>
>
>
> On Sat, Feb 2, 2008 at 8:30 PM, FX Coudert <fxcoudert@gmail.com>  
> wrote:
>> Hi all,
>>
>>  I'm working on a patch to fix the "multiple decls per function"
>>  issue. Current status is good, except for handling of array
>>  arguments, and I need a hand in understand how this is handled. This
>>  is not strictly related to my patch, but lies in the code generated
>>  by the front-end in its current state, although it is uncovered by
>>  the patch :(  I'd be happy to get other maintainers' insight on this
>>  issue, because I'm not too used to array-handling at the tree level.
>>
>>
>>  My patch enables us to reuse already created function decls for a
>>  given function instead of creating a new one each time. If the
>>  function declaration comes first or if an explicit interface is  
>> used,
>>  we can create the function decl easily from the formal arglist. For
>>  implicit interfaces, I chose to recreate the list of argument types
>>  simply by looking at the types in the actual arglist (in its tree  
>> form).
>>
>>  However, in the case where an array is used as argument, that  
>> doesn't
>>  give the same results. For an explicit interface of type
>>
>>      subroutine test(x)
>>        integer x(1)
>>      end subroutine test
>>
>>  the front-end generates for the type of the argument the  
>> following tree:
>>
>>  <pointer_type 0x2aae4c1bc3c0
>>          type <array_type 0x2aae4c1bc000 type <real_type
>>  0x2aae4c1383c0 real(kind=4)>
>>              type_2 SF
>>              size <integer_cst 0x2aae4c11ea50 constant invariant 32>
>>              unit size <integer_cst 0x2aae4c11e6c0 constant  
>> invariant 4>
>>              align 32 symtab 0 alias set -1 canonical type
>>  0x2aae4c1bc000 domain <integer_type 0x2aae4c1bc300>
>>              pointer_to_this <pointer_type 0x2aae4c1bc3c0>>
>>          unsigned type_2 DI
>>          size <integer_cst 0x2aae4c11eb40 constant invariant 64>
>>          unit size <integer_cst 0x2aae4c11eb70 constant invariant 8>
>>          align 64 symtab 0 alias set -1 canonical type  
>> 0x2aae4c1bc3c0>
>>
>>  which is, as far as I understand, correctly marked as an array (see
>>  the "type_2", which is TYPE_LANG_FLAG_2, aka GFC_ARRAY_TYPE_P. On  
>> the
>>  other hand, when the front-end generates code for the following call
>>  (with implicit interface):
>>
>>      integer x(1)
>>      call test(x)
>>
>>  it gives the following type to the x argument :
>>
>>  <pointer_type 0x2b41eda80780
>>          type <array_type 0x2b41eda800c0 type <real_type
>>  0x2b41ed9fc3c0 real(kind=4)>
>>              type_2 SF
>>              size <integer_cst 0x2b41ed9e2a50 constant invariant 32>
>>              unit size <integer_cst 0x2b41ed9e26c0 constant  
>> invariant 4>
>>              align 32 symtab 0 alias set -1 canonical type
>>  0x2b41eda800c0 domain <integer_type 0x2b41eda803c0>
>>              pointer_to_this <pointer_type 0x2b41eda80780>>
>>          unsigned DI
>>          size <integer_cst 0x2b41ed9e2b40 constant invariant 64>
>>          unit size <integer_cst 0x2b41ed9e2b70 constant invariant 8>
>>          align 64 symtab 0 alias set -1 canonical type  
>> 0x2b41eda80780>
>>
>>  It looks right, but it doesn't have the "type_2" flag, ie no
>>  GFC_ARRAY_TYPE_P. Later on, this issue will trigger various asserts
>>  in the front-end (starting with gfc_build_dummy_array_decl, at
>>  fortran/trans-decl.c:740). I believe these asserts are right, and  
>> the
>>  arguments should be marked with GFC_ARRAY_TYPE_P. Do others agree
>>  with this conclusion, and does anyone know where I can start looking
>>  for a place to add it?
>>
>>  Thanks,
>>  FX
>>
>>
>>
>>  PS: my current patch is attached, it regtests and works for valid
>>  code that doesn't involve arrays :)
>>  The testcase that reveals the issue I describe here is:
>>
>>> program test
>>>   real dist(1)
>>>   dist = 1.0
>>>   call f(dist)
>>> end program test
>>>
>>> subroutine f(dist)
>>>   real dist(1)
>>>   if (dist(1) > 0) call abort
>>> end
>>
>>
>>  If you put the subroutine before the main program, the function decl
>>  is generated from the formal arglist, and it works fine. If you keep
>>  it in the order given here, the function decl's args types (ie
>>  TYPE_ARG_TYPES (TREE_TYPE (fndecl)))
>>
>>
>>  PS2: this patch allows good inlining of non-contained procedures, as
>>  well as the -fwhole-program option. It should also allow better
>>  optimization in the middle-end (by having a valid call-graph).

-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/