In:
subroutine foo (i, j)
integer :: i, j, k, l
k = i
l = j
i = i * 10
i = i + j
call baz (i)
i = i + j
end subroutine
subroutine bar (i, j)
integer :: i, j, k, l
k = i
l = j
i = i * 10
i = i + j
call baz (i)
i = i + j
end subroutine
subroutine fn ()
end subroutine fn
program entryval
interface bar
subroutine bar (i, j)
integer :: i, j
end subroutine
end interface
integer :: i
i = 6
call foo (i, 7)
i = 8
call bar (i, 7)
i = 10
call foo (i, 7)
i = 12
call bar (i, 7)
call fn ()
end
the calls to MAIN__, fn_ and baz_ are all treated like varargs call (on
x86_64-linux that means movl $0, %eax or xorl %eax, %eax has to precede each
such call). The patch I'm going to attach fixes at least the callq MAIN__ case
(and should decrease memory consumption by sharing the terminating list nodes).
Unfortunately using if (!typelist) typelist = void_list_node; in
gfc_get_function_type unconditionally isn't right, while it would fix the fn_
case (in -fwhole-file mode we know it has no arguments), for baz_ case which is
external the function really has some arguments, but we don't know them in
gfc_get_function_type. Is there any way to differentiate between the two cases
(when we know the subroutine/function has no arguments and is defined in the
current TU, or when it is unknown)?
Or better yet, can't we for the really extern decls make up the formal
parameters from the call? As in, shouldn't:
subroutine foo (i)
integer :: i
end subroutine foo
program nn
integer :: i
real :: f
call foo (i)
call foo (f)
call bar (i)
call bar (f)
end
warn not just about the argument mismatch to foo, but also about bar?
--
Summary: Functions/subroutines without arguments always treated
like varargs
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45304
