search for: vcpp

...when > built with vs.net, or is there something that I've managed to > mis-build locally? _alloca is used to probe the stack, if you asks for locals of size more that 4k. This is pretty ugly, but the names of this functions differs for mingw32 variant (_alloca) and something like chkstk (vcpp). For mingw32 it's exported in libgcc, dunno about vcpp (probably from some runtime libraries). Since there is no dynamic linking on windows, there is special hook to resolve _alloca call at runtime. Surely, this won't be applicable for lli built by vcpp. Probably, you'll have either...

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 using _alloca which caused the problem, because it felt that target was CygMing. Hacking the output of llvc-gcc from target triple="mingw32&quot...

...r.net> wrote: > > 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 using _alloca which caused the problem, because it felt that target > was CygMing. Hacking the output of llvc-gcc from target triple=&qu...

...nction _alloca which could not be resolved!" I think the problem is the same. But... Cygwin is handled separately, because it's really more unix-like, that e.g. mingw32. Even more, it uses "unix" variant of libSystem. Probably you have to introduce the same hook (as for mingw32 / vcpp) there. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...://www.reaper.fm), and the problem is that when writing 24 bit FLAC files, the data isn't compressed (i.e. the FLAC is slightly larger than if it was writing to .WAV). The files play back fine, however, and 16 bit mode works great. We're using flac-1.1.2, built on win32 with MSVC6 w/ SP5 + VCPP, and NASM version 0.98.39 Any help would be greatly appreciated. Thanks, Justin Frankel justin@blorp.com

It looks fine to me. Anton, does it look ok to you? Evan On Mar 20, 2009, at 2:33 PM, Corrado Zoccolo wrote: > I've created a patch (attached to the bug): > http://llvm.org/bugs/attachment.cgi?id=2744, that goes in a different > direction, and solves the safety problems. > The patch uses original asm, but removes the call through plt, and > puts the invoked function in an

Hi Evan > It looks fine to me. Anton, does it look ok to you? This looks ok for me modulo win64+vcpp issues, which I mentioned in the PR (external .asm files). The anonymous namespace thing should be guarded by define (either _M_AMD64 or X86_64_JIT && _MSC_VER, I'd prefer the latter). -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg...

> The strainge thing is I believe VisualStudio can generate code through it > !:) That's only a belief :) vcpp-generated listings cannot be reassembled into objects via masm :( -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hello, Evan > I am not sure if it has been tested on x86-64 Windows. > Anton, do you know? I don't think it was ever written (for vcpp). There is 32-bit stub only. -- WBR, Anton Korobeynikov

...from GNUWin32 project $ bison --version bison (GNU Bison) 1.875 1.5 Flex 2.5.4 from GNUWin32 project. 2. Patching. 2.1. Libraries Add "LIBS+= -lpsapi -limagehlp" to each makefile (AFTER Makefile.common inclusion) building some tool (burg, tablegen, ll*), since gcc doesn't support vcpp style #pragma's of form: #pragma comment(lib, "dbghelp.lib") 2.2 CopyFile Patch lib/System/Win32/Path.inc in such way, that declaration of CopyFile will look like: void CopyFile(const sys::Path &Dest, const sys::Path &Src) { 2.3 X86 stuff Patch lib/Target/X86/X86SubTarget....

2009/8/3 Anton Korobeynikov <anton at korobeynikov.info> > >> Anyway I wll report back when I have a proper overview of the area, > >> it would be good if you could also look into the problem so contact > >> me back if you are, also it maybe a good idea to share this with > >> Anton and Evan. > > > > I already spoke to anton. The MASM

...9: > 'string' : is not a member of 'std' > - e:\llvm\llvm\include\llvm\ADT\FoldingSet.h(150) : error C2061: > syntax error : identifier 'uint64_t' This really means, that some of includes are missing for your build. For example: uint64_t is typedefed to __int64 for VCPP in include/llvm/Support/DataTypes.h. Please check everything twice. > The windows seems not to know the string type, so you must include it > directly through #include <string>. I did it for some files in > support missing that and it > works fine (it should also not brake UNIX...

Anton Korobeynikov pravi: > Hello, Ziga. > > >> VCPP throws a warning that class is previously declared as struct. >> Either it must be struct everywhere or class everywhere. >> Declaration uses struct, while the definition uses class. >> > Nice! However it will be better to do the opposite: have it struct > everywhere....

Hello, > Unfortunately this did not help :-( Maybe you're using interpreter, not JIT? How you're linking? Also, you don't need C linkage for external stuff, since: - You're using vcpp and there is no dynamic linking on windows - You're calling EE->addGlobalMapping() explicitely -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...blem is that > when writing 24 bit FLAC files, the data isn't compressed (i.e. the > FLAC is slightly larger than > if it was writing to .WAV). The files play back fine, however, and 16 > bit mode works great. > > We're using flac-1.1.2, built on win32 with MSVC6 w/ SP5 + VCPP, and > NASM version 0.98.39 hmm... on the encoding side there are quite a few things that could affect that, so first I'll ask: - are you calling the flac binary or calling into libFLAC? - if flac, what is the command-line string? - if libFLAC, can you post the calls you are using to s...

...r GCC, as far as I am aware, the this pointer is > pushed as if it were a special (first) argument. The fix would > be preaty simple but we want the bytecode to be OS independant, so we > cannot change the bytecode. You're right. There are two flavours of thiscall CC: one using in MS VCPP, another one used by GCC. 1. Visual C++ pointer to this is passed in the ECX register, callee clears the stack, so mirroring stdcall CC. If function is varargs the caller calls the stack, mirroring cdecl CC. 2. GCC Everything is much clearer :) Just standard cdecl CC with one hidden argument (the...

...-special :( > I wasn't able to understand where lli was doing the hooking you > describe though. Once I have some larger functions, I'll dig in more > deeply (or if someone points me at it...). It's in lib/System/Win32/DynamicLibrary.inc I'd suggest you to check, whether vcpp stack probing routine and _alloca has the same signature. If yes - we can easily fix the code emission. Otherwise we'll need extra information about chkstk. -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...how exactly you're compiling LLVM. If you'll go with Cygwin-generated binaries, then yes - you'll need to depend on cygwin1.dll, which cannot be distributed freely, if you'll use mingw - you will use MS CRT, which is present on all win machines. I don't know much details about vcpp build, so I let somebody familiar to complete the answer :) PS: Please post to llvmdev, not to llvm-bugs -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

...4:32:64-f80:32:32-n8:16:32"; >> > > Yep ! Thanks a lot Duncan, obviously not doing my job properly. > > http://llvm.org/viewvc/llvm-project?view=rev&revision=91745 > * > * > "Bump alignment requirements for windows targets to achieve compartibility > with vcpp. Based on patch by Michael Beck!" > > Looks like there is an issue to resolve here. As Cygwin will never be VC++ > compatible its probably not a good idea to change Cygwin's DataLayout as > well as Ming's. > Now, I am getting another regression in stage 2 configure :-...

...ual. I am using interchangeably gcc (RTools) and Visual C++ (via Makefile.win) to build a package. I get a couple of runtime oddities when the dll compiled with Visual C++. I'd value comments, observations and tips from interested readers. I tried my best to find proper compilation settings for VCPP, from a variety of source incl. Duncan Murdoch's advice. Cheers, J-M OBSERVATIONS ============ 1/ The for() loop does not hit the termination condition on args being R_NilValue, and ends up stuck on pointers as shown below, equality never reached. args 0x020e24a0 SEXPREC * R_NilValue 0x83...