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

[Dmitry N. Mikushin]

Dear Anton and Duncan,

Thank you for your insight,
Do you think this is a system problem of gcc applicable to other functions too, or just a flush-specific bug?

Best,
- Dima.

----- Original message -----
> On 17/07/12 08:22, Anton Korobeynikov wrote:
> > Dmitry,
> > 
> > > This is probably a question for Fortran/DragonEGG experts:
> > > 
> > > Why Fortran's "call flush()" is converted to "call void bitcast
> > > (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind"
> > > ? Why it needs bitcast?
> > Just a wild guess (basing from my llvm-gcc knwoledge though): there is
> > a bug with in gcc fortran frontend where it fails to create the
> > function TREEs with proper types. It might easily be possible that
> > e.g. call of function with type with no args is performed with some
> > amount of args, etc. It's pretty fine in gcc, but not in LLVM, the
> > latter is much more strict wrt this.
> > 
> > The only solution / workaround for this was to emit the function
> > definition as variadic and do bitcast at a call site (there are some
> > other fortran-specific stuff involved here, e.g dummy args)...
> > 
> > See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097 for more info.
> > 
> 
> Yes, this is the reason.
> 
> Ciao, Duncan.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu                 http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev