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

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.f90
program 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:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20120717/6d98cd02/attachment.html>

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.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

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.