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

[Duncan Sands]

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, but I didn't get round to implementing
it yet.

Ciao, Duncan.

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