similar to: [LLVMdev] win32 broken again

Hi Jeff, Typically, I've found out that these missing functions are placed beneath lib/System/Unix in some of *.cpp files. These function can be copied to their respectively lib/System/Win32 *.cpp files. Henrik. ----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at

I was trying to build llvm 2.9 using cmake 2.8 ("Nmake Makefiles" generator) and VC++ compiler (version 14.00)... I get the following error. I wonder if anyone has an ideas on hoe I might be able to move past it. using the same method of building for 2.8 works. thanks for any pointers.. Linking CXX executable ..\..\bin\tblgen.exe Creating library ..\..\lib\tblgen.lib and object

Hey everyone, I felt this question is different from my other question - hope this is okay. So - I was playing around with the lookup function of the ExecutionSession and there are some things I don't understand. I have a .BC file with a function "?Sampler@@YAXXZ" referencing a value "?_Plansch_test@@3HA" that is not defined in that module itself. I first planed on not

Hey Lang, Thank you for your help and your patience – also for your answers in the “ORC JIT - Can modules independently managed with one LLJIT instance? + problems with ExecutionSession.lookup” mail. Both problems have the same origin so I keep writing about it here, to avoid duplication. My big problem is still handling cross references between modules with “our” name scheme. Since our old

Hey Lang, > Do you mean that the object file is produced by another process and is being loaded into your JIT process for execution, or that you want your JIT to produce code for several different processes? These are different problems with different solutions. I'll wait until I understand your use case to answer further. In the current state we don’t have a JIT only an handcrafted object

Hey Lang, Woah! That mail contains a lot of information and things I never tried yet… Actually… the entire MaterializationUnit and MaterializationResponsibility part is… quite… overwhelming >O< With “pop up” I mean… the process which is waiting for Module “Planschi” to “pop up” can not do a thing about it. It just waits until there is an table entry for it, indicating that the object file

list.files() (and dir()) don't appear to return names of directories when one uses the recursive=T argument. E.g., > dir(file.path(R.home(),"library"), pattern="^R$", recursive=T) [1] "Malmig/help/R" but the unix find commmand finds lots of R directories > z <- system(paste("find", file.path(R.home(),"library"), "-name

I tried checking out the latest llvm/clang from SVN (as of a few hours ago) and compiling it (clang 3.6.1 doesn't compile 3.7 because it fails a version check, so I repeated the technique of compiling with Microsoft C++ first, then using the resulting clang-cl.exe). It fails with a bunch of error messages along the lines of: LLVMSupport.lib(Atomic.obj) : error LNK2019: unresolved external

How can i replicate this in Linux: source(file.choose()) I've tried source(tkgetOpenFile()) but with no luck

R 1.5.1 is due to come out ... and I've just noticed that the R help.start page search applet doesn't work on my Mandrake 8.2 system even though I've upgraded mozilla to version 1.0 and I have a perfectly working java (all right, I'm using 1.4.0 now, but with mozilla 0.98 and java 1.3.1 it still didn't work). I had thought the problem due to a too-old mozilla version, but it

Hi Michael, Please keep in mind non-C/C++ frontends. For example, in Rust, we promise to avoid all undefined behavior in safe code. There is no reasonable compositional analysis that can statically detect stack overflows (I know safety-critical systems are subjected such analyses, but those could not reasonably be enforced on all Rust code -- most of them just forbid recursion, for example), so

Makes sense, yeah, trying something in a different environment is usually a good way to find problems. I had indeed moved the renamed clang-cl.exe to a different directory, but when I move it back into its home directory and retry the build, I get the same errors. On Thu, Jun 11, 2015 at 11:16 PM, Reid Kleckner <rnk at google.com> wrote: > Thanks for trying the self-host, it's

During the review of https://reviews.llvm.org/D59978 we got to the question whether we can optimize based on the assumption that stack overflow is undefined behavior. While I think it is according to the C++ standard, Windows Structured Exception Handling and signal handlers might allow programs to recover/exit gracefully. Concretely, the patch D59978 wants add the noreturn attribute to functions

Hi, Probably some of the leaks Valgrind reports are spurious, but the numbers seem to be significant enough to demand some attention: ==10132== LEAK SUMMARY: ==10132== definitely lost: 15,624 bytes in 558 blocks. ==10132== indirectly lost: 44,548 bytes in 1,591 blocks. ==10132== possibly lost: 37,576 bytes in 98 blocks. ==10132== still reachable: 1,336,876 bytes in 1,364 blocks.

Primitive Unix I/O should not be used outside of lib/System: c:\llvm\lib\Bytecode\Reader\ReaderWrappers.cpp(140) : error C2039: 'read' : is not a member of 'operator``global namespace'''

Jeff, Thanks for reporting this. I had no idea ::read was being used in ReaderWrappers. I have re-implemented it using istream facilities. This should be much more portable. Please try again and let me know if its better. Thanks, Reid. On Mon, 2004-12-20 at 22:31, Jeff Cohen wrote: > Primitive Unix I/O should not be used outside of lib/System: > >

On Fri, Dec 5, 2008 at 1:52 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > / * snip */ Actually, rebuilding it makes "debug tblgen" fail with the errors at the end of this email, and as such everything that depends on it, how odd... When I get back to that computer then I will clean its directory, update from SVN (please fix the const thing soon :) ), and rebuild fresh...

On Fri, Mar 23, 2012 at 9:45 PM, JonY <jon_y at users.sourceforge.net> wrote: > On 3/23/2012 13:59, Glenn McCord wrote: >> Hi. I'm trying to get a project linking to libFLAC_static.lib but I >> get linker errors such as the following. >> >> The __imp__ prefix seems to imply that some kind of .dll usage is >> happening, which it shouldn't. >>

On Fri, Dec 5, 2008 at 1:57 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: > On Fri, Dec 5, 2008 at 1:52 PM, OvermindDL1 <overminddl1 at gmail.com> wrote: >> / * snip */ > > Actually, rebuilding it makes "debug tblgen" fail with the errors at > the end of this email, and as such everything that depends on it, how > odd... > When I get back to that

Does not seem to be a straight error with LLVM itself, but rather the tools, linking issues, here are the errors: Opt: 30> Creating library R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.lib and object R:\SDKs\llvm\trunk_VC8_building\lib\Debug\opt.exp 30>LLVMScalarOpts.lib(IndVarSimplify.obj) : error LNK2019: unresolved external symbol "public: bool __thiscall