Displaying 2 results from an estimated 2 matches for "test1_".
Did you mean:
test1
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" ?
...4-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 @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...
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,