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

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.

Dear Anton and Duncan,

Thank you for your insight,
Do you think this is a system problem of gcc applicable to other functions too,
or just a flush-specific bug?

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

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
>