[PATCH] D48240: Try again to implement a FIFO task queue

[Zachary Turner via llvm-commits]

This whole file is supposed to be ifdefed out in this case. Is it not? I
definitely tested this case
On Tue, Jun 26, 2018 at 6:39 AM Nico Weber via Phabricator <
reviews at reviews.llvm.org> wrote:

> thakis added a comment.
>
> In https://reviews.llvm.org/D48240#1141268, @zturner wrote:
>
> > This patch deletes the `LLVM_ENABLE_THREADS=0` codepath and just errors
> out if you try to use this class in those circumstances.  Since the regular
> codepath is actually pretty straightforward and doesn't have much
> complexity, I went ahead and added support for tasks that return values
> directly to this patch.  It was only a couple of line change and saves me
> from having to make another patch for it.
>
>
> Unsurprisingly this breaks the LLVM_ENABLE_THREADS=0 build:
>
>   FAILED:
> unittests/Support/CMakeFiles/SupportTests.dir/TaskQueueTest.cpp.o
>
> /b/build/slave/linux_upload_clang/build/src/third_party/llvm-bootstrap-install/bin/clang++
>  -DGTEST_HAS_PTHREAD=0 -DGTEST_HAS_RTTI=0 -DGTEST_HAS_TR1_TUPLE=0
> -DGTEST_LANG_CXX11=1 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iunittests/Support
> -I/b/build/slave/linux_upload_clang/build/src/third_party/llvm/unittests/Support
> -I/usr/include/libxml2 -Iinclude
> -I/b/build/slave/linux_upload_clang/build/src/third_party/llvm/include
> -I/b/build/slave/linux_upload_clang/build/src/third_party/llvm/utils/unittest/googletest/include
> -I/b/build/slave/linux_upload_clang/build/src/third_party/llvm/utils/unittest/googlemock/include
> --gcc-toolchain=/b/build/slave/linux_upload_clang/build/src/third_party/llvm-build-tools/gcc485precise
> -fPIC -fvisibility-inlines-hidden -Werror=date-time
> -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
> -Wmissing-field-initializers -pedantic -Wno-long-long
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor
> -Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections
> -O3    -UNDEBUG  -Wno-variadic-macros
> -Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -fno-rtti -MMD -MT
> unittests/Support/CMakeFiles/SupportTests.dir/TaskQueueTest.cpp.o -MF
> unittests/Support/CMakeFiles/SupportTests.dir/TaskQueueTest.cpp.o.d -o
> unittests/Support/CMakeFiles/SupportTests.dir/TaskQueueTest.cpp.o -c
> /b/build/slave/linux_upload_clang/build/src/third_party/llvm/unittests/Support/TaskQueueTest.cpp
>   In file included from
> /b/build/slave/linux_upload_clang/build/src/third_party/llvm/unittests/Support/TaskQueueTest.cpp:10:
>
> /b/build/slave/linux_upload_clang/build/src/third_party/llvm/include/llvm/Support/TaskQueue.h:84:5:
> error: static_assert failed "TaskQueue requires building with
> LLVM_ENABLE_THREADS!"
>       static_assert(false,
>       ^             ~~~~~
>
> What's the thinking here? Maybe TaskQueueTest.cpp shouldn't be part of the
> build if LLVM_ENABLE_THREADS=0? As-is, this just gives you a compile error
> if you use that option and build all targets (like our bots do).
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D48240
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180626/c7b80647/attachment-0001.html>