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 nonsensically expanded to a cl > intrinsic (_mm_mfence). This breaks the Visual Studio build. > > The trivial fix is to #undef MemoryFence immediately after including > <windows.h>, since it's clearly assumed not to exist. A deeper and > safer fix might consider avoiding a name conflict with a core system > macro on a widely used platform.Wait, it defines MemoryFence() AND MemoryBarrier()?? Sheesh, they had to take all the reasonable names. :-/ --Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090528/8202b1f7/attachment.bin>
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. :-/
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 reasonable names. :-/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2620 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090602/3781e7c1/attachment.bin>
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 names. :-/ > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev