llvm dev - Apr 2015 - [LLVMdev] LLVM_ENABLE_THREADING=ON by default in Windows, is this right?

I'm not sure what LLVM_ENABLE_THREADS impacts - whether it is LLVM
executables themselves or LLVM-generated code - but it seems to be on by
default on the Windows CMake build (I'm building LLVM+Clang at trunk head
using CMake/Visual Studio 2013 Win64).

But 3 unit tests in IR, which are compiled only if define
LLVM_ENABLE_THREADS is set, fail if LLVM_ENABLE_THEADS=ON:
ValueMapTest/{0,1,2}.LocksMutex.

Should LLVM_ENABLE_THREADS be OFF for the Windows Visual Studio builds?  Or
something else?  Should something about this switch be documented at the
"Building LLVM With CMake" page, e.g., here
http://llvm.org/docs/CMake.html#llvm-specific-variables ?

Thanks -- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150404/78b506f0/attachment.html>

In general, LLVM_ENABLE_THREADS should default to 'ON' and it is
supported.

I can reproduce your test failures by running IRTests.exe directly, but not
when using lit or the 'check' target. I think this failure slipped in
silently because of a bug in lit's interaction with gtest. This patch makes
the failure visible in the suite:

--- a/utils/lit/lit/formats/googletest.py
+++ b/utils/lit/lit/formats/googletest.py
@@ -95,7 +95,7 @@ class GoogleTest(TestFormat):
             # Handle GTest parametrized and typed tests, whose name
includes
             # some '/'s.
             testPath, namePrefix = os.path.split(testPath)
-            testName = os.path.join(namePrefix, testName)
+            testName = namePrefix + '/' + testName

         cmd = [testPath, '--gtest_filter=' + testName]
         if litConfig.useValgrind:

I'm running the suite with this now to see if it uncovers other Windows
specific failures. I plan to disable these tests on Windows until we can
figure out what's up.

On Sat, Apr 4, 2015 at 4:06 PM, David Bakin <davidbak at gmail.com> wrote:
> I'm not sure what LLVM_ENABLE_THREADS impacts - whether it is LLVM
> executables themselves or LLVM-generated code - but it seems to be on by
> default on the Windows CMake build (I'm building LLVM+Clang at trunk
head
> using CMake/Visual Studio 2013 Win64).
>
> But 3 unit tests in IR, which are compiled only if define
> LLVM_ENABLE_THREADS is set, fail if LLVM_ENABLE_THEADS=ON:
> ValueMapTest/{0,1,2}.LocksMutex.
>
> Should LLVM_ENABLE_THREADS be OFF for the Windows Visual Studio builds?
> Or something else?  Should something about this switch be documented at the
> "Building LLVM With CMake" page, e.g., here
> http://llvm.org/docs/CMake.html#llvm-specific-variables ?
>
> Thanks -- David
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150406/1dd613af/attachment.html>

David,

To clarify:
>     I'm not sure what LLVM_ENABLE_THREADS impacts - whether it is LLVM
>     executables themselves
Yes, and the various llvm libraries too.
> or LLVM-generated code
No.
>
>     Thanks -- David
>
Jon

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

Thanks for verifying this!  I haven't actually been able to run tests
successfully under lit yet, even though I think I'm following the
instructions.  But thanks for looking to see what works and what doesn't.
I'm just starting with Clang, using CMake/Visual Studio, and one of my main
issues so far is not being able to verify via the test-suite that
everything is built correctly - unit tests run perfectly, but some of the
other tests have unexpected failures (*) and I'm not sure whether that's
my
setup or just the current state of affairs.

-- David

(*) The failures are in clang, and nearly all of those failures involve
"could not acquire lock file for module 'Module'" pointing at
an "@import
Module" which makes me think I've got something wrong with the module
system.

On Mon, Apr 6, 2015 at 1:14 PM, Reid Kleckner <rnk at google.com> wrote:
> In general, LLVM_ENABLE_THREADS should default to 'ON' and it is
supported.
>
> I can reproduce your test failures by running IRTests.exe directly, but
> not when using lit or the 'check' target. I think this failure
slipped in
> silently because of a bug in lit's interaction with gtest. This patch
makes
> the failure visible in the suite:
>
> --- a/utils/lit/lit/formats/googletest.py
> +++ b/utils/lit/lit/formats/googletest.py
> @@ -95,7 +95,7 @@ class GoogleTest(TestFormat):
>              # Handle GTest parametrized and typed tests, whose name
> includes
>              # some '/'s.
>              testPath, namePrefix = os.path.split(testPath)
> -            testName = os.path.join(namePrefix, testName)
> +            testName = namePrefix + '/' + testName
>
>          cmd = [testPath, '--gtest_filter=' + testName]
>          if litConfig.useValgrind:
>
> I'm running the suite with this now to see if it uncovers other Windows
> specific failures. I plan to disable these tests on Windows until we can
> figure out what's up.
>
> On Sat, Apr 4, 2015 at 4:06 PM, David Bakin <davidbak at gmail.com>
wrote:
>
>> I'm not sure what LLVM_ENABLE_THREADS impacts - whether it is LLVM
>> executables themselves or LLVM-generated code - but it seems to be on
by
>> default on the Windows CMake build (I'm building LLVM+Clang at
trunk head
>> using CMake/Visual Studio 2013 Win64).
>>
>> But 3 unit tests in IR, which are compiled only if define
>> LLVM_ENABLE_THREADS is set, fail if LLVM_ENABLE_THEADS=ON:
>> ValueMapTest/{0,1,2}.LocksMutex.
>>
>> Should LLVM_ENABLE_THREADS be OFF for the Windows Visual Studio builds?
>> Or something else?  Should something about this switch be documented at
the
>> "Building LLVM With CMake" page, e.g., here
>> http://llvm.org/docs/CMake.html#llvm-specific-variables ?
>>
>> Thanks -- David
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150406/0f7be50c/attachment.html>