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

[Duncan Sands]

Hi Dmitry, it would be neater to use stripPointerCasts.

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 <mailto: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.
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>