Dmitry N. Mikushin
2012-Jul-17 00:37 UTC
[LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
Dear LLVM, 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? I'm expecting something like "call void @_gfortran_flush_i4(i8* null)". Otherwise, we will need to teach our call parsers to digg into bitcasts, which is an undesired extra complexity. Below is a test case (dragonegg/llvm as of r156703):> cat flush.f90program test call flush() end program test> kernelgen-dragonegg flush.f90 -o- | opt -O3 -S -o -; ModuleID = '<stdin>' target datalayout "e-p:64:64:64-S128-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f16:16:16-f32:32:32-f64:64:64-f128:128:128-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64" target triple = "x86_64-unknown-linux-gnu" @options.0.1537 = internal constant [8 x i32] [i32 68, i32 511, i32 0, i32 0, i32 0, i32 1, i32 0, i32 1], align 32 declare void @_gfortran_flush_i4(...) define i32 @main(i32 %argc, i8** %argv) nounwind uwtable { entry: tail call void @_gfortran_set_args(i32 %argc, i8** %argv) nounwind tail call void @_gfortran_set_options(i32 8, i32* getelementptr inbounds ([8 x i32]* @options.0.1537, i64 0, i64 0)) nounwind tail call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind ret i32 0 } declare void @_gfortran_set_args(i32, i8**) declare void @_gfortran_set_options(i32, i32*) -- Thanks, - Dima. -------------- next part -------------- An HTML attachment was scrubbed... URL: <lists.llvm.org/pipermail/llvm-dev/attachments/20120717/6d98cd02/attachment.html>
Anton Korobeynikov
2012-Jul-17 06:22 UTC
[LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
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 gcc.gnu.org/bugzilla/show_bug.cgi?id=33097 for more info. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University
Duncan Sands
2012-Jul-17 07:48 UTC
[LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
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 gcc.gnu.org/bugzilla/show_bug.cgi?id=33097 for more info. >Yes, this is the reason. Ciao, Duncan.
Seemingly Similar Threads
- [LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
- [LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
- [LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
- [LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
- [LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?