similar to: [LLVMdev] Cygwin and FreeBSD broken

The attached patch prevents MappedMemoryTest.BasicWrite and MappedMemoryTest.MultipleWrite (both in unittests/Support/MemoryTest.cpp) from running if the correct protection flags for memory allocation are not set. Without this patch, the two tests fail when I run "make check-all" on a mips octeon board. The problem with the current code is that it allocates a block of memory without

Hello I installed the game "Cursed Mountain", with no problems, at the end of the installation it asked for launching the game, and the game ran successfully. Later I wanted to launch it again, but now it gets stuck after the logo intro. The terminal output is: Code: --------------------------------------------------- KTM --------------------------------------------------- Version:

There is a typo that breaks FreeBSD: Compiling Memory.cpp In file included from /usr/home/llvm/lib/System/Memory.cpp:28: /usr/home/llvm/obj/lib/System/platform/Memory.cpp: In static member function `static void llvm::sys::Memory::ReleaseRWX(llvm::sys::Memory&)': /usr/home/llvm/obj/lib/System/platform/Memory.cpp:47: error: `sterror' undeclared (first use this function)

Look good. -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Akira Hatanaka Sent: Tuesday, December 04, 2012 1:33 PM To: LLVM Developers Mailing List Subject: [LLVMdev] [PATCH][Review request] MappedMemoryTest: Prevent tests from running if read flag is not set. The attached patch prevents MappedMemoryTest.BasicWrite and

Hi LLVM folks, Attached with this email, you will find a patch not directly applicable (it doesn't compile like this) which (try to) enhance the structure of a possible JIT with the MC framework. Basically : - MCJIT : - Main class implementing ExecutionEngine interface - owns and creates : - a MemoryManager (will be a reuse of the JITMemoryManager mechanism) - a MCJITStreamer

Morten, The leaks.patch file introduced a static destructor ordering problem which lead to garbled output. The comment above those lines of code indicates why it needs to be the way it is. My bad for committing it in the first place. Please be careful in the future. Reid. On Mon, 2004-12-13 at 05:30, Morten Ofstad wrote: > Hi, > > here are some minor patches that for various reasons

Folks, I have recently committed several lib/System changes. As with previous commits, the changes work on Linux but for other platforms I'm only "guessing" at the implementation based on available documentation. Your mileage might vary. If this breaks compilation on your platform, please correct the implementation and check it in or submit patches to me and I'll check it in.

FreeBSD does not define pthread_mutexattr_setpshared: gmake[1]: Entering directory `/usr/home/jeffc/llvm/obj/lib/System' llvm[1]: Compiling Mutex.cpp for Release build /usr/home/jeffc/llvm/obj/../lib/System/Mutex.cpp:42: warning: the address of `int llvm::pthread_mutex_init(llvm::pthread_mutex**, llvm::pthread_mutex_attr* const*)', will always evaluate as `true'

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

On Tue, 14 Sep 2004 08:02:10 -0700 Jeff Cohen <jeffc at jolt-lang.org> wrote: > On Mon, 13 Sep 2004 20:54:57 -0700 > Reid Spencer <reid at x10sys.com> wrote: > > > On the other hand, no one has submitted any Win32 patches yet, so first > > come first served :) > > > > Reid. > > Consider this a down payment :) The Win32 version of Memory.cpp

Hi Jeff and Morten, I was just wondering if below wisdom is true, why not prefix every solution and project file with VC71 in front of the file name to signal the case that it is only designed for that specific IDE/tool? This gives us room for comming up with other solution and project files for another MS specific IDE/tool independt of each other. Henrik. ----Original Message Follows----

Well... that didn't take long. I'm not sure what you did, Reid, with Path.cpp, but it broke VC++: Bytecode.lib(ReaderWrappers.obj) : error LNK2001: unresolved external symbol "public: __thiscall llvm::sys::Path::Path(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0Path at sys@llvm@@QAE at

----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfileor directory Date: Thu, 23 Dec 2004 08:05:39 -0800 >Yes, it

It's a possibility, though it would be better to create whole separate trees for different versions of VS. It's not just the project and solutions that need to be kept separate; the object files themselves cannot be mixed between different versions of VS. There's no rush though. Trust me, C/C++ programmers will not rush to adopt Whidbey once it's released. You'd be

----Original Message Follows---- From: Jeff Cohen <jeffc at jolt-lang.org> Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': No suchfile or directory Date: Tue, 21 Dec 2004 16:29:47 -0800

I successfully build llvm from cvs using vs2005 and stlport. I also had a couple of issues, but most were due to outdated project files. I also had to implement code for the alloca instruction. On 3/10/07, Jeff Cohen <jeffc at jolt-lang.org> wrote: > > The recent issues concern the head revision, post 1.9. As no one has > ever submitted patches to fix 2005 problems with the 1.9

I agree completely with you, Jeff. However, I think it somehow would be nice, if you guys could tell comming users that the win32 solution is geared toward VC++ 7.1 (and hence use of other tools are at their own risk). And, I think it also would be really cool, if you guys come up with a solution how to handle multiple VC++ x solutions/projects from the same source, possibly ranging from VC

Henrik Bach wrote: > ----Original Message Follows---- > From: Jeff Cohen <jeffc at jolt-lang.org> > Reply-To: jeffc at jolt-lang.org, LLVM Developers Mailing List > <llvmdev at cs.uiuc.edu> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Subject: Re: [LLVMdev] VC++: Cannot open include file: 'windows.h': > No suchfileor

Yes, it should find windows.h with the default configuration. But you have to be suspicious of beta code that Microsoft gives out for free. It might just be very buggy, or it might be deliberately crippled. Considering the price tag on Visual Studio, it's one or the other (and probably both). Out of curiosity, did it accept the solution and project files as is, or did it want to

On 3/10/07, Jeff Cohen <jeffc at jolt-lang.org> wrote: > It is, if only because it's the version I use, but 2005 is supposed to > work also. That being said, I wouldn't be surprised to learn that it > doesn't due to recent STL issues. Versions prior to 2003 won't work. I'm using the basic stuff (just libraries, 1.9) with 2005, although we had to fix a few