[Fortran] PR 48174+45304: No varags if interface is known

This patch makes sure that there is no vararg if the procedure interface 
is known. Before, for functions and subroutines without arguments, no 
void_list_node.

(Related, separate and unfixed issue: For procedures without explicit 
interface, the interface should be deduced from the usage.)

Build and regtested on x86-64-linux.
OK for the trunk?

Tobias

Dear Tobias,

Why did Jakub's patch for PR45304 not fix this?  He visited the fix in
your patch upon build_library_function_decl_1 and
gfc_get_intrinsic_lib_fndecl.  Should
trans-decl.c(create_function_arglist) have received the same
treatment?

Otherwise it is OK for trunk.

Thanks for the patch.

Paul

On Tue, Mar 22, 2011 at 9:21 AM, Tobias Burnus <burnus@net-b.de> wrote:
> This patch makes sure that there is no vararg if the procedure interface is
> known. Before, for functions and subroutines without arguments, no
> void_list_node.
>
> (Related, separate and unfixed issue: For procedures without explicit
> interface, the interface should be deduced from the usage.)
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
>

Hi Tobias...

I've been a lurker here since I posted a problem with varargs (stdarg, 
really) interfaces back on May 31, 2010 ("Variable argument call does 
not work on 64-bit gfortran").  You were able to determine that my 
problem existed on gfortran 4.1 but was fixed in all of 4.2 through 4.6, 
although you weren't sure how it got fixed.  We switched to 4.4 and 
everything worked fine.  I appreciate the help!!

This proposed patch is probably okay but makes me nervous.  However, the 
"related" issue scares me.  Referring to my original email, we have a 
large legacy f77 system with 15,000 calls to C stdarg functions. 
Because the stdarg and non-stdarg ABI appears to be different for x86_64 
platforms, these need to be called using the stdarg ABI.

So I hope you can understand why I might be nervous when something is 
tweaked in this area!

Our code does not declare these routines to Fortran, therefore the 
procedure interface is unknown and this patch "should" not bother 
anything.  But for the related issue... deducing the interface from 
usage is likely to break things badly in my case (and doesn't sound very 
robust in any case).  Unless I'm misunderstanding the application of the 
issue?

Would it be possible for you to try my test case again after this patch, 
just to make sure?  I can post it again if you like.

Thanks...

-Bob

Bob Deen  @  NASA-JPL Multimission Image Processing Lab
Bob.Deen@jpl.nasa.gov


On 3/22/11 1:21 AM, Tobias Burnus wrote:
> This patch makes sure that there is no vararg if the procedure interface
> is known. Before, for functions and subroutines without arguments, no
> void_list_node.
>
> (Related, separate and unfixed issue: For procedures without explicit
> interface, the interface should be deduced from the usage.)
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias

Dear Paul,

Paul Richard Thomas wrote:
> Why did Jakub's patch for PR45304 not fix this? He visited the fix in
> your patch upon build_library_function_decl_1 and
> gfc_get_intrinsic_lib_fndecl.

Well, my patch is in a way a follow up to Jakub's. His patch only fixed 
the library call definitions and the (in gfc_get_function_type) ensured 
that for decl with formal arguments and for the main function the void 
list is added.

Thus, no void list was added if there was no formal arglist. Well, this 
patch changes this to still add the void list, if it is known that there 
are no arguments.

> Should trans-decl.c(create_function_arglist) have received the same treatment?

I don't think so - though I might be wrong.

Committed as Rev. 171519.

Tobias

Dear Bob,

Bob Deen wrote:
> Our code does not declare these routines to Fortran, therefore the 
> procedure interface is unknown and this patch "should" not bother 
> anything.

Well, it also affects:

   SUBROUTINE foo()
   END SUBROUTINE foo
and
   REAL FUNCTION bar()
   END FUNCTION bar

that is procedures without arguments, including functions which do not 
return an argument. However, without looking at the debug output 
(DWARF), it should not be visible for the generated program - and it 
should not cause any issues.

> But for the related issue... deducing the interface from usage is 
> likely to break things badly in my case (and doesn't sound very robust 
> in any case).  Unless I'm misunderstanding the application of the issue?

I think deducing the interface should work fine; I think C does the 
same, if no prototype has been specified.

I am not sure what it means for your test case [1], thus, one probably 
should test it before. However, no patch to address that issue exists, 
yet. I have added your test program as comment to PR 44471 [2]

[1] http://gcc.gnu.org/ml/fortran/2010-05/msg00330.html
[2] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44471

Tobias