search for: _gfortran_flush_i4

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/l...

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

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

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

Hi Anton, >> How do you think what would be the best way to workaround this problem, if >> it seems to be not in focus for anybody for now? > Keep in mind, this not LLVM problem, it's gfortran problem. Also, it's > of pretty low priority for gcc devs since they do almost no type > checking on TREEs, so the varargs decl seems to be only viable > llvm-side fix.

> Oh, right, now I remember: it's a very old problem I knew 1.5 years ago. > There were even some bugs on it, here is a common case: Yes, this is right, fortran frontend produces bogus trees for every external call. The problem seems to have roots from the fact that there is no external function decl here, so frontend has no way even to infer the type from. > How do you think what

Hi Anton, On 17/07/12 15:35, Anton Korobeynikov wrote: >> actually there is a different fix, which is to not pay any attention to GCC >> function types when generating calls (and function prototypes), and instead >> do everything by querying GCC's CUMULATIVE_ARGS. > I tried to do this during llvm-gcc times and it turned out that there > might be different calls with

Thanks, Duncan, makes sense! I suppose you meant something like this: Function* callee = dyn_cast<Function>( call->getCalledValue()->stripPointerCasts()); if (!callee) continue; - D. 2012/7/17 Duncan Sands <baldrick at free.fr> > Hi Dmitry, it would be neater to use stripPointerCasts. > > Ciao, Duncan.

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

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

> actually there is a different fix, which is to not pay any attention to GCC > function types when generating calls (and function prototypes), and instead > do everything by querying GCC's CUMULATIVE_ARGS. I tried to do this during llvm-gcc times and it turned out that there might be different calls with different signatures in single module e.g. function with N arguments is called

Hi Dmitry, it would be neater to use stripPointerCasts. Ciao, Duncan. > OK, at our end the following workaround seems to be sufficient: > > // Check if function is called (needs -instcombine pass). > Function* callee = call->getCalledFunction(); > if (!callee) > { >

OK, at our end the following workaround seems to be sufficient: // Check if function is called (needs -instcombine pass). Function* callee = call->getCalledFunction(); if (!callee) { // Could be also a function called inside a bitcast. // So try to extract function

...arameter_dt*, i8*, i32)* @_gfortran_transfer_real_write to void (%struct.__st_parameter_dt*, float*, i32)*)(%struct.__st_parameter_dt* %dt_parm.15, float* %D.1628, i32 4) nounwind call void @_gfortran_st_write_done(%struct.__st_parameter_dt* %dt_parm.15) nounwind call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* null) nounwind %284 = bitcast [0 x float]* %100 to i8* %285 = icmp ne i8* %284, null br i1 %285, label %"50", label %"51" "50": ; preds = %"49" call void @free(i8* %284) nounwind br la...

...@_gfortran_transfer_real_write to void (%struct.__st_parameter_dt*, float*, > i32)*)(%struct.__st_parameter_dt* %dt_parm.15, float* %D.1628, i32 4) > nounwind > call void @_gfortran_st_write_done(%struct.__st_parameter_dt* > %dt_parm.15) nounwind > call void bitcast (void (...)* @_gfortran_flush_i4 to void (i8*)*)(i8* > null) nounwind > %284 = bitcast [0 x float]* %100 to i8* > %285 = icmp ne i8* %284, null > br i1 %285, label %"50", label %"51" > > "50": ; preds = %"49" > call voi...