similar to: [LLVMdev] bitcast function calls

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

Artur, > OK, I just need the same signature for both of those instructions. Both are callinsts of same function, isn't that enough? Since it's a variadic function there is also a bitcast to proper type. So, looking for type of callee (not result, but function type!) you'll obtain the real "signature" of callee and if you'll strip all pointer cast you'll obtain the

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

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

Hello, > The function is declared in a header file. How? As 'void openBMPJPG()' ? > After linkingall the files together, the callee function is called in > the way bellow: 'void openBMPJPG()' will give you varargs function declaration. So, actually you're calling no-args function via vargargs declaration. Thus bitcast there. -- With best regards, Anton

> 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

Duncan, 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: > cat test1.f90 program test call test1() end program test > kernelgen-dragonegg test1.f90 -o- | opt -O3 -S -o - ; ModuleID = '<stdin>' target datalayout =

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

We are seeing some behavior we don't understand. Some of our functions are not showing up in the Call Graph because their calls contain bitcasts. The Call Graph then considers them to be external nodes. The calls look as follows: %tmp35 = call i32 (...)* bitcast (i32 (i32, i8*, i32*)* @convert to i32 (...)*)( i32 %tmp33, i8* %tmp34, i8* %tmp30 ) ; <i32> [#uses=1] After looking

Hi Anton, You're already a part of the llvm development team by participating actively on the llvm development list :) If you wish we can put you on: http://llvm.cs.uiuc.edu/Developers.html Great to have you on the team, welcome! We (Jeff, Morten, Paolo, the rest of the team and I) are looking forward to cooperate with you and to push win32 and mingw versions even further to stable and

Hi, Artur > The interesting for me part of the CallInst is printf(i8* noalias %0, i32 > 123). > I was diging in doxygen documentation but I really can't see the easy way to > compare those instructions and again finish with reinvented (but working) > wheel ;). Ah, sorry. I missed that you're doing variadic calls, not casting variadic function to definite ones. I think you

Hi Thanks for the info, it led to the source of the error I was having. I was using llvm-gcc binaries (built with mingw I guess) to compile a .c file that is my language runtime, llvm-link'ing that with my frontend's .ll, and using an vcpp-built lli to run the resulting bytecode. This caused the special case in X86RegisterInfo::emitPrologue for "main" to try to align the stack

How can a frontend tell LLVM to put a function argument on stack/register/etc? On Thu, Oct 4, 2012 at 5:08 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Ah, got it. >> Sounds like we might need to introduce CC_X86_Win32_MSVC_ThisCall then?.. > No, we should not. It should be properly expanded in frontend. > > -- > With best regards, Anton Korobeynikov >

I tried to ask for 32 and that didn't seem to help. MallocInst also seemed to ignore the 16 byte directive. For now, I'm just issuing all my loads as unaligned and that's working ok. Thanks, Chuck. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Evan Cheng Sent: Monday, October 01, 2007 10:35 AM To: asl at

---------- Forwarded message ---------- From: lost <lostfreeman at gmail.com> Date: 2010/6/5 Subject: Re: [LLVMdev] Passing structures by value on Windows To: Anton Korobeynikov <anton at korobeynikov.info> Ok, but how to bitcast structure? Documentation<http://llvm.org/docs/LangRef.html#i_bitcast>says that bitcast does not applicable to aggregate values. 2010/6/3 Anton

The alloca hook is in lib\System\Win32\DynamicLibrary.inc all the way at the bottom. You'll see a __MING32__ #ifdef around the definition. You just have to implement those methods and it'll work just fine. Jake On 6/24/07, Scott Graham <scott.llvm at h4ck3r.net> wrote: > > Hi > > Thanks for the info, it led to the source of the error I was having. > > I was using

Hello, Bill. > Has anyone gotten the latest/greatest sources from the LLVM-GCC open > source server lately? No. It's still at rev 319 (as of 29.04). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Bill, > When I try to compile on Darwin now, I get this: Could you please provide LLVM bytecode, where bug is reproducible with llc? -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hello, Rafael > With this patch I was able to bootstrap gcc in linux x86-64 with > shared libraries enabled :-) Awesome! But... -ENOPATCH :( -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.