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

> 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

Hi Anton,

On 17/07/12 15:35, Anton Korobeynikov wrote:
>> 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...
yes, it is a can of worms, but I'm hopeful it can be made to work anyway.

Ciao, Duncan.

OK, at our end the following workaround seems to be sufficient:

                    // Check if function is called (needs -instcombine
pass).
                    Function* callee = call->getCalledFunction();
                    if (!callee)
                    {
                        // Could be also a function called inside a bitcast.
                        // So try to extract function from the underlying
constant expression.
                        // Required to workaround GCC/DragonEGG issue:
                        //
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051786.html
                        ConstantExpr* expr
dyn_cast<ConstantExpr>(call->getCalledValue());
                        if (!expr) continue;
                        callee =
dyn_cast<Function>(expr->getOperand(0));
                    }

*Hopefully* there will be no more gcc-generated special cases :)

Thanks,
- D.

2012/7/17 Duncan Sands <baldrick at free.fr>
> Hi Anton,
>
>
> On 17/07/12 15:35, Anton Korobeynikov wrote:
>
>> 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...
>>
>
> yes, it is a can of worms, but I'm hopeful it can be made to work
anyway.
>
> Ciao, Duncan.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120717/4cfa6257/attachment.html>