Displaying 3 results from an estimated 3 matches for "_gfortran_set_args".
2012 Jul 17
2
[LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
...quot;
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_arg...
2012 Jul 17
0
[LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
...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 @test1_(...)
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 (...)* @test1_ to void ()*)() nounwind
ret i32 0
}
declare void @_gfortran_set_args(i32, i8**)
declare v...
2012 Jul 17
2
[LLVMdev] [DragonEgg] Why Fortran's "call flush()" is converted to "call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind" ?
Hi Dmitry,
> Do you think this is a system problem of gcc applicable to other functions too, or just a flush-specific bug?
it has nothing to do with flush - for all I know flush is fine. Dragonegg
does this for all Fortran functions because the Fortran front-end is so buggy,
i.e. often produces wrong function types. I have another way of handling this
in mind, which would avoid this trick,