search for: threadsupport

...Mac OS X (I just did a CVS up and it will take another hour or two to build), but I'm having an issue with building on Linux. Specifically, "lli" fails to link because it now needs to link against libpthread, because it ends up pulling in ExecutionEngine.h which in turn pulls in ThreadSupport.h. I'm wondering how this should be fixed, because I'm afraid it may not be a simple problem. So the first question is, to which Makefile do I need to add the "-lpthread" flag to get the thing to compile? The next issue is what is the *right* way to do this: 1. Some platforms...

...ct MaxThreadsParser : public llvm::cl::parser<unsigned> { bool parse(llvm::cl::Option &O, llvm::StringRef ArgName, llvm::StringRef Arg, unsigned &Val); }; But that's now causing: In file included from /home/lak/my_svn/llvm-carte/llvm-3.7.0/tools/carte++/tools/ir2v/ThreadSupport.cpp:1: /home/lak/my_svn/llvm-carte/llvm-3.7.0/tools/carte++/tools/ir2v/ThreadSupport.h:12:34: error: base 'parser' is marked 'final' struct MaxThreadsParser : public llvm::cl::parser<unsigned> { What's the new way to do this now? It looks like the documentation at h...

...carefully. I tried to make getModule return a constant reference, but that quickly led me into deep trouble in the world of const correctness. I've attached my patch against the latest CVS. There is one "trivial" fix which should be committed, even if this patch is incorrect. In ThreadSupport.h, the include guard macro needs to have "LLVM_" prefixed to it. The ThreadSupport-PThread.h and ThreadSupport-NoSupport.h files look for the macro with this prefix. Thank you, Evan Jones -------------- next part -------------- A non-text attachment was scrubbed... Name: llvm-threadsa...

...n-freebsd5.2.1 checking host system type... i386-unknown-freebsd5.2.1 checking target system type... i386-unknown-freebsd5.2.1 test: Unknown: bad number And finally: config.status: creating Makefile.config config.status: creating include/Support/DataTypes.h config.status: creating include/Support/ThreadSupport.h config.status: creating include/Support/hash_map config.status: creating include/Support/hash_set config.status: creating include/Support/iterator config.status: creating include/Config/config.h config.status: linking ../lib/System/Unknown to lib/System/platform config.status: error: ../lib/Syste...

...just did a CVS up and it will take another hour or two to build), but > I'm having an issue with building on Linux. Specifically, "lli" fails to link > because it now needs to link against libpthread, because it ends up pulling > in ExecutionEngine.h which in turn pulls in ThreadSupport.h. I'm wondering > how this should be fixed, because I'm afraid it may not be a simple problem. Ah, ok. > So the first question is, to which Makefile do I need to add the "-lpthread" > flag to get the thing to compile? The next issue is what is the *right* way > t...

...05-08-27 at 11:47 -0700, Reid Spencer wrote: > Alkis Evlogimenos wrote: > > It seems that these two classes are the same... Maybe they should be > > merged into 1 class? > > > I think you're looking at something old. MutexLocker doesn't exist any more. llvm/Support/ThreadSupport.h is not generated anymore? -- Alkis

...... i386-unknown-freebsd5.2.1 > checking target system type... i386-unknown-freebsd5.2.1 > test: Unknown: bad number > > And finally: > > config.status: creating Makefile.config > config.status: creating include/Support/DataTypes.h > config.status: creating include/Support/ThreadSupport.h > config.status: creating include/Support/hash_map > config.status: creating include/Support/hash_set > config.status: creating include/Support/iterator > config.status: creating include/Config/config.h > config.status: linking ../lib/System/Unknown to lib/System/platform > conf...

...lativePath="..\..\include\llvm\Support\StableBasicBlockNumbering.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\SystemUtils.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\ThreadSupport-NoSupport.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\ThreadSupport-PThreads.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\Timer.h"> > + </File> > +...

Hi, when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32patches.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041115/34634455/attachment.txt>

It seems that these two classes are the same... Maybe they should be merged into 1 class? -- Alkis

Alkis Evlogimenos wrote: > It seems that these two classes are the same... Maybe they should be > merged into 1 class? > I think you're looking at something old. MutexLocker doesn't exist any more. Reid.

...checking target system type... i386-unknown-freebsd5.2.1 > > test: Unknown: bad number > > > > And finally: > > > > config.status: creating Makefile.config > > config.status: creating include/Support/DataTypes.h > > config.status: creating include/Support/ThreadSupport.h > > config.status: creating include/Support/hash_map > > config.status: creating include/Support/hash_set > > config.status: creating include/Support/iterator > > config.status: creating include/Config/config.h > > config.status: linking ../lib/System/Unknown to lib/...

...ocking it when particular state is accessed. Note that the JIT subclasses this in lib/ExecutionEngine/JIT/JIT.h, so its accesses should be synchronized as well. The only really tricky thing about this is making the locking portable across platforms. However, I think the include/llvm/Support/ThreadSupport.h file should export what you need. > What about the LLVM interpreter, for situations where there is no JIT? Is it > thread-safe? Yes, I believe it is thread safe. However, is not widely used and is REALLY slow (even for an interpreter). >>> Does anyone have any thoughts about...

On Feb 8, 2005, at 21:36, Chris Lattner wrote: > That is correct. If you try to run threaded programs in the JIT, it > might run into problems if multiple functions need to JIT functions at > the same time. This should be very simple to deal with, we just > haven't had anyone take up the task yet. Only the JIT is affected > here, not the static code generator or C

...nclude\llvm\Support\StableBasicBlockNumbering.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Support\SystemUtils.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Support\ThreadSupport-NoSupport.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Support\ThreadSupport-PThreads.h"> > > </File> > > <File > > RelativePath="..\..\include\llvm\Support\Timer.h"> > &...

...RelativePath="..\..\include\llvm\Support\StableBasicBlockNumbering.h"> > </File> > <File > RelativePath="..\..\include\llvm\Support\SystemUtils.h"> > </File> > <File > RelativePath="..\..\include\llvm\Support\ThreadSupport-NoSupport.h"> > </File> > <File > RelativePath="..\..\include\llvm\Support\ThreadSupport-PThreads.h"> > </File> > <File > RelativePath="..\..\include\llvm\Support\Timer.h"> > </File> > <Fi...