[LLVMdev] gfortran calling convention

[Chris Lattner]

On Fri, 1 Sep 2006, Michael McCracken wrote:
> Here's what works now, and I have a separate test case for each of these:
>
> statement functions
> intrinsic functions (print, cos, etc)
> loops, goto statments
> scalarized array operations
> function calls with *no arguments*
> simple common blocks

Great!

> Function calls with more than one argument don't work. Specifically:
>
> ..../gfortran funccall-1arg.f -o funccall-1arg.exe
> ..../llvm/lib/VMCore/Instructions.cpp:209: failed assertion
> `(Params.size() == FTy->getNumParams() || (FTy->isVarArg() &&
> Params.size() > FTy->getNumParams())) && "Calling a function with bad
> signature!"'
> funccall-1arg.f: In function 'MAIN__':
> funccall-1arg.f:5: internal compiler error: Abort trap
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://llvm.org/bugs> for instructions.
> make: *** [funccall-1arg.exe] Error 1

Okay, this is probably due to the fact that the prototype for the function 
isn't beeing matched up with the number of formals in the trees.  At the 
point of the assertion, what does "FTy->dump()" print to, and what do each 
of the params in the Params array print to?

> While I didn't entirely understand the cause from the backtraces and
> inspection in the debugger, I did notice that there is not yet a
> calling convention in CallingConv.h for Fortran, and llvm-convert only
> tests for CallingConv:C and CSRet, so I suspect that the different CCs
> is a problem here.

I don't think that that would be necessary, gfortran (IIUC) uses C calling 
conventions for easy interop.

> It looks like I will have to implement a complement to the
> FunctionCallArgumentConversion class in llvm-convert.c for the Fortran
> CC, but I'm not clear on the role of the CallingConv ID enum. Does a
> Fortran CC belong in there, or is that only for the back end?

I don't *think* you'll need to do that, the first thing to find out is why 
the prototype for the function doesn't match up with the arguments. 
There are two likely answers:

1. We're handling a formal argument incorrectly.
2. We're building the prototype incorrectly.

Figuring out which of the two is happening is important.  If it's #2, 
getting the output of "debug_tree(x)" on the function type "tree" node 
would be useful.  If it's #1, getting the output of debug_tree(x) on the 
argument node that isn't getting converted correctly would be useful.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/