llvm dev - Jul 2012 - [LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?

> Oh, right, now I remember: it's a very old problem I knew 1.5 years
ago.
> There were even some bugs on it, here is a common case:
Yes, this is right, fortran frontend produces bogus trees for every
external call.
The problem seems to have roots from the fact that there is no
external function decl here, so frontend has no way even to infer the
type from.
> How do you think what would be the best way to workaround this problem, if
> it seems to be not in focus for anybody for now?
Keep in mind, this not LLVM problem, it's gfortran problem. Also, it's
of pretty low priority for gcc devs since they do almost no type
checking on TREEs, so the varargs decl seems to be only viable
llvm-side fix.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi Anton,
>> How do you think what would be the best way to workaround this problem,
if
>> it seems to be not in focus for anybody for now?
> Keep in mind, this not LLVM problem, it's gfortran problem. Also,
it's
> of pretty low priority for gcc devs since they do almost no type
> checking on TREEs, so the varargs decl seems to be only viable
> llvm-side fix.
actually there is a different fix, which is to not pay any attention to GCC
function types when generating calls (and function prototypes), and instead do
everything by querying GCC's CUMULATIVE_ARGS.

Ciao, Duncan.

> actually there is a different fix, which is to not pay any attention to GCC
> function types when generating calls (and function prototypes), and instead
> do everything by querying GCC's CUMULATIVE_ARGS.
I tried to do this during llvm-gcc times and it turned out that there
might be different calls with different signatures in single module
e.g. function with N arguments is called in some cases with N - 1
first args and since the remaining one is unused everything is fine.
So, basically the function *is* varargs but it's not possible to
deduce this from the args...

I don't recall all the details now though...

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University