Thanks, Duncan, makes sense! I suppose you meant something like this:<br><br>                    Function* callee = dyn_cast<Function>(<br>                        call->getCalledValue()->stripPointerCasts());<br>
                    if (!callee) continue;<br><br>- D.<br><br><div class="gmail_quote">2012/7/17 Duncan Sands <span dir="ltr"><<a href="mailto:baldrick@free.fr" target="_blank">baldrick@free.fr</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Dmitry, it would be neater to use stripPointerCasts.<br>
<br>
Ciao, Duncan.<br>
<div class="im"><br>
> OK, at our end the following workaround seems to be sufficient:<br>
><br>
>                      // Check if function is called (needs -instcombine pass).<br>
>                      Function* callee = call->getCalledFunction();<br>
>                      if (!callee)<br>
>                      {<br>
>                          // Could be also a function called inside a bitcast.<br>
>                          // So try to extract function from the underlying<br>
> constant expression.<br>
>                          // Required to workaround GCC/DragonEGG issue:<br>
>                          //<br>
> <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051786.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-July/051786.html</a><br>
>                          ConstantExpr* expr =<br>
> dyn_cast<ConstantExpr>(call->getCalledValue());<br>
>                          if (!expr) continue;<br>
>                          callee = dyn_cast<Function>(expr->getOperand(0));<br>
>                      }<br>
><br>
> *Hopefully* there will be no more gcc-generated special cases :)<br>
><br>
> Thanks,<br>
> - D.<br>
><br>
</div>> 2012/7/17 Duncan Sands <<a href="mailto:baldrick@free.fr">baldrick@free.fr</a> <mailto:<a href="mailto:baldrick@free.fr">baldrick@free.fr</a>>><br>
<div class="im HOEnZb">><br>
>     Hi Anton,<br>
><br>
><br>
>     On 17/07/12 15:35, Anton Korobeynikov wrote:<br>
><br>
>             actually there is a different fix, which is to not pay any attention<br>
>             to GCC<br>
>             function types when generating calls (and function prototypes), and<br>
>             instead<br>
>             do everything by querying GCC's CUMULATIVE_ARGS.<br>
><br>
>         I tried to do this during llvm-gcc times and it turned out that there<br>
>         might be different calls with different signatures in single module<br>
>         e.g. function with N arguments is called in some cases with N - 1<br>
>         first args and since the remaining one is unused everything is fine.<br>
>         So, basically the function *is* varargs but it's not possible to<br>
>         deduce this from the args...<br>
><br>
>         I don't recall all the details now though...<br>
><br>
><br>
>     yes, it is a can of worms, but I'm hopeful it can be made to work anyway.<br>
><br>
>     Ciao, Duncan.<br>
><br>
><br>
><br>
><br>
</div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br>