On Sat, Apr 16, 2011 at 8:34 AM, Tobias Burnus <bur...@net-b.de> wrote:
> Steve Kargl wrote:
>>
>> The comment comes from r170414, which suggest there is a problem if a
>> procedure is in an argument list, and that procedure gets in-lined.
>> [...]
>> Perhaps, looking at the -fdump-tree-original on whole_file_32.f90 may shed
>> light on the situation.
>
> Well, it does not. The function gets inlined - and looks OK - the function
> itself remains as it is externally visible. There is also no ICE, which is
> not surprising otherwise the testsuite had failed.
>
> For completeness, the optimized (-O3 -finline-small-functions) dump looks as
> follows:
>
> ;; Function phload (phload_)
> phload (integer(kind=4) (*<T403>) () reader)
> {
> integer(kind=4) _result_reader;
> <bb 2>:
> _result_reader_2 = reader_1(D) ();
> return 1;
> }
>
> ;; Function main (main) (executed once)
> main (integer(kind=4) argc, character(kind=1) * * argv)
> {
> static integer(kind=4) options.0[8] = {68, 511, 0, 0, 0, 1, 0, 1};
> <bb 2>:
> _gfortran_set_args (argc_1(D), argv_2(D));
> _gfortran_set_options (8, &options.0[0]);
> r ();
> return 0;
> }
>
>
> while the source file is the following:
>
> SUBROUTINE PHLOAD (READER,*)
> IMPLICIT NONE
> EXTERNAL READER
> CALL READER (*1)
> 1 RETURN 1
> END SUBROUTINE
>
> program test
> EXTERNAL R
> CALL PHLOAD (R, *999) ! This one is OK
> 999 continue
> END program test
>
>
> Thus: OK for the trunk?
Indeed all "exceptions" not to use the single backend-decl are
suspicious and may simply hide
other problems. Note that the middle-end has to deal with indirect
calls becoming direct calls
but with mismatched arguments fine already (by simply not trying
anything fancy). So, if you
hit problems in the middle-end with even strictly invalid Fortran
input it's a middle-end problem.
Richard.
> Tobias
>
