search for: memoryfs

In the current trunk, System/Atomic.[h,cpp] define void llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in <windows.h> and (since it's a preprocessor macro, and not a scoped function definition) causes the sys::MemoryFence definition on Atomic.cpp:23 to explode, as it's nonsensically expanded to a cl intrinsic (_mm_mfence). This breaks the Visual Studio build.

On May 28, 2009, at 6:03 PM, Jonathan Ragan-Kelley wrote: > In the current trunk, System/Atomic.[h,cpp] define void > llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in > <windows.h> and (since it's a preprocessor macro, and not a scoped > function definition) causes the sys::MemoryFence definition on > Atomic.cpp:23 to explode, as it's

On May 17, 2009, at 12:32 PM, Chris Lattner wrote: > Owen, I would really rather that you didn't take this path. Threading > support in LLVM should always be optional: it should be possible to > use LLVM on systems where we don't have support for threading > operations. Indeed, some systems don't support threads! I'm not trying to make it required. I had provided

Is this actually the case? I can't find it documented anywhere on MSDN or the rest of the internet. --Owen On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. > > On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: >> >> Wait, it defines MemoryFence() AND MemoryBarrier()?? >> >> Sheesh, they had to take all the

Owen Anderson wrote: > Is this actually the case? I can't find it documented anywhere on > MSDN or the rest of the internet. C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F MemoryFence WinNT.h 2231:#define MemoryFence _mm_mfence C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include>grep -n -F MemoryBarrier WinNT.h 2288:#define MemoryBarrier __faststorefence

Andrew Haley brought up this interesting issue on the GCC mailing-list that directly affect the stability of the ARM llvm target when using multi-threading. http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00600.html basically using __sync_synchronize() with GCC on ARM does not generate any code for the fence. For what I know: The only working fix for this issue on Linux would be to create a call to

Hello, I trying TSAN on Darwin on LLVM itself (sanitizing multi-threaded ThinLTO link). However I see two main issues on my debug build: 1) Statistics: the pre/post increment is not safe, it seems to be acknowledge in the code itself: // FIXME: This function and all those that follow carefully use an // atomic operation to update the value safely in the presence of // concurrent

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

Yes, indeed. On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: > > Wait, it defines MemoryFence() AND MemoryBarrier()?? > > Sheesh, they had to take all the reasonable names.  :-/

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

...little more detail? > How can you be sure the file actually exists on the FS? That's what the VFS should be all about, hiding this abstraction... if you *are* sure it exists, or want to make sure, you need to pull the appropriate realFS from the VFS Overlay (most tools have an overlay of a memoryFS above the realFS). That makes sense, for LLDB's use case we would be happy having just a real or redirecting filesystem (with fall through). > What I am not sure about is extending the general interface in a way that it caters to a particular (or half of a particular) use case. I totally...

I'd like to get some more perspectives on the role of the VirtualFileSystem abstraction in llvm/Support. (The VFS layer has recently moved from Clang to LLVM, so crossposting to both lists) https://reviews.llvm.org/D54277 proposed adding a function to VirtualFileSystem to get the underlying "real file" path from a VFS path. LLDB is starting to use VFS for some filesystem

Hi, We use LLVM libraries to compile C++ code and noticed slow downs when multiple threads of a process were compiling at once. *perf *indicated that most of the CPU time was spent in a spin lock, which was being locked/unlocked from llvm::PassRegistry::getPassInfo(). We read the relevant LLVM code and found out that PassRegistry is a ManagedStatic and is shared among all threads in case of a

On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. Are they macros or functions? If macros, why not just #undef them at the top of Atomics.h? -Chris > > > On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: >> >> Wait, it defines MemoryFence() AND MemoryBarrier()?? >> >> Sheesh, they had to take all the reasonable

On Aug 24, 2009, at 1:32 AM, Duncan Sands wrote: > unfortunately, race detectors like helgrind don't like this kind of > thing, and report it as a race. Last time I asked about it I was > told that fixing it would be too hard/expensive. I know, and it's somewhat unfortunate. However, this path is extremely hot in LLC, and was significantly contended using only two threads. I

Hi, Some time in the last few weeks I noticed my cmake build of svn-trunk on powerpc-darwin8 start to warn about atomics being unavailable and thus building thread-unsafe. I just looked into it and found an easy solution, using the atomic functions in <libkern/OSAtomic.h> in /usr/include. The attached patch does this and also modifies the cmake and autoconf tests to 'pass'

Stefan Hajnoczi <stefanha at gmail.com> writes: > On Sat, Jun 8, 2013 at 7:39 PM, Laszlo Ersek <lersek at redhat.com> wrote: >> Patches before the last are small cleanups. >> >> In the last patch I'm trying to extract / generalize an idea from Stefan >> Hajnoczi's review of my virtio-net driver for OVMF. How about a single patch which just replaces

Stefan Hajnoczi <stefanha at gmail.com> writes: > On Sat, Jun 8, 2013 at 7:39 PM, Laszlo Ersek <lersek at redhat.com> wrote: >> Patches before the last are small cleanups. >> >> In the last patch I'm trying to extract / generalize an idea from Stefan >> Hajnoczi's review of my virtio-net driver for OVMF. How about a single patch which just replaces

I was able to process further by making some code changes and replacing export-dynamic with -bexpfull in Makefile.config. Now, i am getting following error while linking .. llvm[3]: Linking Release+Asserts Loadable Module LLVMHello.so ld: 0706-027 The -R $ORIGIN flag is ignored. ld: 0711-317 ERROR: Undefined symbol: llvm::Pass::getPassName() const ld: 0711-317 ERROR: Undefined symbol:

Hi All, I am trying to build llvm on AIX. I installed all the required packages including gcc, g++, etc ./configure also went fine. but i tried to run gmake, i got the following error: llvm[1]: Compiling MemoryBuffer.cpp for Release+Asserts build llvm[1]: Compiling MemoryObject.cpp for Release+Asserts build llvm[1]: Compiling Mutex.cpp for Release+Asserts build llvm[1]: Compiling Path.cpp for