[LLVMdev] gfortran calling convention

[Michael McCracken]

Hi,
I commented out the assertion in TreeConstantToLLVM::Convert that I
mentioned in an earlier message, so I could keep looking at the
function call issue.

On 9/2/06, Chris Lattner <sabre at nondot.org> wrote:
> On Fri, 1 Sep 2006, Michael McCracken wrote:

[snip]

> > 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?

At the point of the assertion, llvm-convert.c:1851 ,
FTy->dump()  is invalid, giving me an invalid memory location:
>(gdb) print FTy->dump()
>Cannot access memory at address 0x10
I get CallOperands.size() = 0
and FTy->getNumParams() = 146542211

"print *FTy" gives me this:

(gdb) print *FTy
$2 = {
  <DerivedType> = {
    <Type> = {
      <AbstractTypeUser> = {
        _vptr$AbstractTypeUser = 0x0
      },
      members of Type:
      ID = 69,
      Abstract = true,
      RefCount = 0,
      ForwardType = 0x39800000,
      ContainedTys = {
        <_Vector_base<llvm::PATypeHandle,std::allocator<llvm::PATypeHandle>
>> = {
          _M_impl = {
            <allocator<llvm::PATypeHandle>> = {
              <new_allocator<llvm::PATypeHandle>> = {<No data
fields>}, <No data fields>},
            members of _Vector_impl:
            _M_start = 0x0,
            _M_finish = 0x45e07420,
            _M_end_of_storage = 0x0
          }
        }, <No data fields>},
      AbstractTypeUsers = {
        <_Vector_base<llvm::AbstractTypeUser*,std::allocator<llvm::AbstractTypeUser*>
>> = {
          _M_impl = {
            <allocator<llvm::AbstractTypeUser*>> = {
              <new_allocator<llvm::AbstractTypeUser*>> = {<No data
fields>}, <No data fields>},
            members of _Vector_impl:
            _M_start = 0x0,
            _M_finish = 0x45e2abd0,
            _M_end_of_storage = 0x45e2b780
          }
        }, <No data fields>},
      static VoidTy = 0x40a6cd60,
      static BoolTy = 0x40a6cd38,
      static SByteTy = 0x40a6cd10,
      static UByteTy = 0x40a6cce8,
      static ShortTy = 0x40a6ccc0,
      static UShortTy = 0x40a6cc98,
      static IntTy = 0x40a6cc70,
      static UIntTy = 0x40a6cc48,
      static LongTy = 0x40a6cc20,
      static ULongTy = 0x40a6cbf8,
      static FloatTy = 0x40a6cbd0,
      static DoubleTy = 0x40a6cba8,
      static LabelTy = 0x40a6cb80
    }, <No data fields>},
  members of FunctionType:
  isVarArgs = false
}

> > 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.

OK, I wasn't sure about that - I saw some code in gfortran to use
'f2c-style' calling convention, but I couldn't tell right away how
that changed things.

> > 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.

At this point, it is looking like #2 to me...

Here is the debug_tree(exp) output with the program stopped at
llvm-convert.cpp:1786

 <call_expr 0x45e2ac00
    type <real_type 0x45e0ae00 real4 SF
        size <integer_cst 0x45e05600 constant invariant 32>
        unit size <integer_cst 0x45e05120 constant invariant 4>
        align 32 symtab 1084672976 alias set -1 precision 32
        pointer_to_this <pointer_type 0x45e0af80>>
    side-effects
    arg 0 <addr_expr 0x45e2abd0
        type <pointer_type 0x45e2e080 type <function_type 0x45e2cf80>
            unsigned SI size <integer_cst 0x45e05600 32> unit size
<integer_cst 0x45e05120 4>
            align 32 symtab 1183916800 alias set -1>
        constant invariant
        arg 0 <function_decl 0x45e2e000 print_one_num type
<function_type 0x45e2cf80>
            addressable used public external asm-frame-size 0 SI file
funccall-1.f line 5
            LLVM: float ()* %print_one_num_ chain <function_decl
0x45e2cd00 MAIN__>>>
    arg 1 <tree_list 0x45e2b780
        value <addr_expr 0x45e2aba0 type <pointer_type 0x45e12100>
            invariant arg 0 <const_decl 0x45e2cf00 C.264>>>
    funccall-1.f:5>

Here is the whole program I'm trying to compile:

	program derivatives

	real x, dx, diff1, diff2

	diff1 = print_one_num(1)     <-- Line 5, tree seen above.

	end

	function print_one_num(x)

	print * ,'Function print_one_num ', x
	print_one_num = 0.0
	return

	end

-mike

-- 
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/