rfc: multiple decls for functions

[Mikael Morin]

Daniel Franke wrote:
> On Tuesday 23 December 2008 00:17:37 Mikael Morin wrote:
>> 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.
> 
> Thanks for looking into this.
> 
> Maybe I'm thick, but there's one point that still doesn't make any sense to 
> me: why are there any regressions like these at all? Why is it suddenly 
> necessary to fiddle and twiddle at so many places because of special cases? 
> Although we currently have two or more backend_decls for the same function, 
> each of them seems to work individually. When merging the available 
> information into one backend_decl, why is it suddenly necessary to change 
> things that don't need to be changed in the current implementation? Or do they 
> need changing but it doesn't show?

I'm not sure.
Without the patch, we create a function declaration for a function call
and another one for the function definition.
With the patch, we try to guess the function interface matching the
function call. But it can be wrong. Think about pointers for example.
A void pointer is enough for a function call, but the actual pointer
type is needed to compile the function itself.

In the following example, the interface of the subroutine foo is not
known at the time call bar (foo) is compiled.
!!!!!!!!!!!!!!!!!
external :: foo

call bar (foo)
end

subroutine bar (f)
interface
	subroutine f
	end subroutine
end interface
call f
end subroutine bar

subroutine foo
end subroutine
!!!!!!!!!!!!!!!!!

Hum, forget. The above compiles fine.
Well, I don't know :-(.

Mikael