This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Question about array types in the front-end


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]