size_t size = 63; void *ptr = scalable_malloc(size); size += 4; ptr = scalable_realloc(ptr, size);

And then when running the following command:
sde -hsw -- TestTbbMalloc.exe
An access violation is received in tbbmalloc.dll!___intel_memcpy

The problem does not happen when compiling tbbmalloc from source using Visual Studio. I guess this is related to memcpy substituted by ICL.
Reproduced on 2017 Update 5(Windows).
The same code does not crash on real Haswell CPU without emulator.

I'm working on an environment for building packages of third party libraries used by our project, and TBB is one of those libraries. We download third party source code from the upstream (like GitHub in case of TBB) and build it ourselves. One part of the job is to ensure that whatever is downloaded is genuine, so we verify the SHA-256 checksum of the downloaded source code.

With TBB we discovered that the source code of a shipped release is not persistent and can change without any notification. This was the case with 2017u7, which was first released on 2017-06-04 (the .tar.gz archive SHA-256 was 755b7dfaf018f5d8ae3bf2e8cfa0fa4672372548e8cc043ed1eb5b22a9bf5b72) and currently the tag corresponds to a commit on 2017-06-07 (SHA-256: 78ad6ec9dd492b9dcc4753938b06716f7458506084adc138ced09aa0aa609b6b).

This is a big problem for us because we cannot know what code is the 2017u7 version and we cannot be sure that any of the source releases is genuine. Please, change your release practices.

I'm getting a compiler error

[...]tbb\task_group.h(94): error C2530: 'my_task': references must be initialized

since I've updated Visual Studio to version 15.7.1 (possibly also 15.7).

Just including the main header tbb/tbb.h causes the error to occur (no additional code required). I've also opened a question on stackoverflow.

System info:

• TBB 2018 Update 3 (just rebuild it using vcpkg package manager, tbb:x64-windows package)
• Visual Studio 15.7.1
• Windows 10 Pro x64 1709 (build 16299.431)

.sig orphan file: no counterpart .xbps package file, only the last version has it.

Excerpt of https://repo.voidlinux.eu/current/musl/:

2bwm-0.1_1.armv6l-musl.xbps.sig                    15-Sep-2016 21:50                 512
2bwm-0.1_1.armv7l-musl.xbps.sig                    15-Sep-2016 21:52                 512
2bwm-0.1_1.x86_64-musl.xbps.sig                    16-Sep-2016 11:40                 512
2bwm-0.2_1.armv6l-musl.xbps                        27-Mar-2017 14:25               25892
2bwm-0.2_1.armv6l-musl.xbps.sig                    27-Mar-2017 14:27                 512
2bwm-0.2_1.armv7l-musl.xbps                        27-Mar-2017 14:25               25956
2bwm-0.2_1.armv7l-musl.xbps.sig                    27-Mar-2017 14:27                 512
2bwm-0.2_1.x86_64-musl.xbps                        27-Mar-2017 14:22               27872
2bwm-0.2_1.x86_64-musl.xbps.sig                    27-Mar-2017 14:25                 512

As discussed here: http://devel.fedoraproject.narkive.com/tVmi6KvD/how-to-package-so-linker-scripts
the content of the linker script file should rather start with a comment:

/* GNU ld script
This file is used during build-time linking with Intel(R) Threading Building Blocks library.
If it is referred directly as run-time dependency, it means an application is built incorrectly using symlinks. */

For example and comparison, this is what libc.so contains:

$ cat /usr/lib/x86_64-linux-gnu/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a  AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ) )

We are trying to use tbb::concurrent_vector with polymorphic allocators:

template <typename T>
using PolymorphicAllocator = boost::container::pmr::polymorphic_allocator<T>;
// this could also be std::experimental

template <typename T>
using pmr_concurrent_vector = tbb::concurrent_vector<T, PolymorphicAllocator<T>>;

Two problems come with this:

First, the vector tries to use the move allocator for the vector which was deleted by p0337r0. Since propagate_on_container_move_assignment is not set, the allocator should not be moved. Changing concurrent_vector.h:745 from

            if (pocma_t::value) {
                this->my_allocator = std::move(other.my_allocator);
}

to

            if constexpr (pocma_t::value) {
                this->my_allocator = std::move(other.my_allocator);
}

would fix this.

Second, the vector is using rebind here, which was deprecated in c++17. Any chance we can get rid of that?

Running make shows the below "Known issues". It would be better to document them in the ReadMe or something.

./test_concurrent_queue.exe
Known issue: C++11 smart pointer tests are skipped.
done
./test_concurrent_vector.exe
Known issue: initializer list tests are skipped.
Known issue: tests for vector move constructor/assignment operator are skipped.
Warning: not much concurrency in TestConcurrentGrowBy (0 inversions)
Warning: not much concurrency in TestConcurrentGrowBy (0 inversions)
Warning: not much concurrency in TestConcurrentGrowBy (37 inversions)
Known issue: exception safety tests for move constructor/assignment operator , grow_by are skipped.
Known issue: C++11 reference wrapper tests are skipped.
Known issue: C++11 smart pointer tests are skipped.
done
./test_concurrent_unordered_set.exe
Known issue: C++11 smart pointer tests are skipped.
done
./test_concurrent_unordered_map.exe
Known issue: C++11 smart pointer tests are skipped.
done
./test_concurrent_hash_map.exe
Known issue: tests for C++11 move semantics support are skipped.
Known issue: C++11 reference wrapper tests are skipped.
Known issue: C++11 smart pointer tests are skipped.
done

Hi,
Will there be support for visual studio 2017 community edition?

Problem: \include\tbb\concurrent_unordered_map.h(48): error C2143: syntax error: missing ',' before '<'

\include\tbb\concurrent_unordered_map.h(61): note: see reference to class template instantiation 'tbb::interface5::concurrent_unordered_map_traits<Key,T,Hash_compare,Allocator,Allow_multimapping>::value_compare' being compiled

\include\tbb\concurrent_unordered_map.h(70): note: see reference to class template instantiation 'tbb::interface5::concurrent_unordered_map_traits<Key,T,Hash_compare,Allocator,Allow_multimapping>' being compiled

When: A parallel_for code compiling on VS2017 with compiler parameter /std:c++latest. Compiling with /std:c++14 does not produce the issue.

Hi,

I develop some software that relies on TBB. One of my users is seeing intermittent hanging behavior that seems to be coming from the scheduler during a parallel_for loop (COMBINE-lab/salmon#111). The linked issue has a lot of data, including gdb traces that show the offending stacks. I've tried both the default and simple partitioner, but both exhibit this behavior. The code executing inside the parallel for has no locks or mutexes, though it does use an enumerable_thread_specific. Any idea what might be triggering this behavior or how to resolve it?

Continuum Analytics feedback: Exposing a pkg-config interface for TBB, or something similar (such as llvm-config), sounds like a good way to avoid hard-coding environment-related definitions in every third party project.
TBBROOT is not enough in order to configure application with correct compiler and linker flags needed to build an application which uses TBB.
See the issues related in this PR: numba/numba#2217 (review)

For more information see https://people.freedesktop.org/~dbn/pkg-config-guide.html
It can be done for binary TBB package and can be generated as yet another kind of tbbvars during the build from sources

Please take a look how conda implements this (e.g. here) through additional CI stage "clahub" linked to https://www.clahub.com/agreements/conda/conda-build

As the title says. Given that my_number_of_buckets is uninitialized, the following code has undefined behavior. Upon calling find() it either crashes (my_number_of_buckets == 0), spins for a long time (my_number_of_buckets is very large), or may seem to work. It is also reported by valgrind.

Case 1: Move constructor

#include <cstring>
#include <tbb/concurrent_unordered_map.h>

using tbb_map = tbb::concurrent_unordered_map<int, int>;

int main(int argc, const char* argv[]) {
  // Zero out enough stack to make sure it crashes. Assumes standard 2MB Linux stack size.
  {
     char buffer[100000];
     std::memset(&buffer, 0x0, sizeof(buffer));
  }

  tbb_map one;
  tbb_map two(std::move(one));
  auto it = one.find(5);
  return 0;
}

Case 2: Move assignment operator
This case is harder to make crash or do something funky in my machine. In my machine, after the move operation, one.my_number_of_buckets becomes 16. It should equal initial_bucket_number, 8.

#include <cstring>
#include <tbb/concurrent_unordered_map.h>

using tbb_map = tbb::concurrent_unordered_map<int, int>;

int main(int argc, const char* argv[]) {
  // Zero out enough stack to make sure it crashes. Assumes standard 2MB Linux stack size.
  {
     char buffer[100000];
     std::memset(&buffer, 0x0, sizeof(buffer));
  }
  tbb_map one, two;
  two = std::move(one);
  auto it = one.find(5);
  return 0;
}

Case 2: Alternate implementation
For whatever reason, I have more success in getting clearly incorrect behavior with this test

#include <vector>
#include <tbb/concurrent_unordered_map.h>

using tbb_map = tbb::concurrent_unordered_map<int, int>;

int main(int argc, const char* argv[]) {
  std::vector<tbb_map> vec;
  vec.emplace_back(tbb_map());
  auto& one = vec.back();
  tbb_map two;
  two = std::move(one);
  auto it = one.find(5);
  return 0;
}

Environment: centos, GCC 6.4, debug, tbb 2017 (but similar code in 2018 version)
Compilation options: -Wall -Werror
Our code

if (!queue.try_pop (hit)) {
    break;
}

produce compilation warning from tbb impl code:

    // tbb/2017/include/tbb/internal/_concurrent_queue_impl.h:285
    page& p = *head_page;
    __TBB_ASSERT( &p, NULL );

New version of gcc/clang produce this warning because compiler believes variable on stack cannot have null dereference. I think code with assert should be reworked.

Compiler warning:

tbb/2017/include/tbb/internal/_concurrent_queue_impl.h: In instantiation of ‘bool tbb::strict_ppl::internal::micro_queue<T>::pop(void*, tbb::strict_ppl::internal::ticket, 
tbb::strict_ppl::internal::concurrent_queue_base_v3<T>&) [...]’:
tbb/2017/include/tbb/internal/_concurrent_queue_impl.h:563:14:   required from ‘bool tbb::strict_ppl::internal::concurrent_queue_base_v3<T>::internal_try_pop(void*) [...]’
tbb/2017/include/tbb/concurrent_queue.h:153:48:   required from ‘bool tbb::strict_ppl::concurrent_queue<T, A>::try_pop(T&) [...]’
<out file>: required from here
tbb/2017/include/tbb/internal/../tbb_stddef.h:138:50: error: the compiler can assume that the address of ‘p’ will always evaluate to ‘true’ [-Werror=address
address]
  #define __TBB_ASSERT_RELEASE(predicate,message) ((predicate)?((void)0) : tbb::assertion_failure(__FILE__,__LINE__,#predicate,message))
                                                  ^
tbb/2017/include/tbb/internal/../tbb_stddef.h:162:45: note: in expansion of macro ‘__TBB_ASSERT_RELEASE’
     #define __TBB_ASSERT(predicate,message) __TBB_ASSERT_RELEASE(predicate,message)
                                             ^~~~~~~~~~~~~~~~~~~~
tbb/2017/include/tbb/internal/_concurrent_queue_impl.h:285:5: note: in expansion of macro ‘__TBB_ASSERT’
     __TBB_ASSERT( &p, NULL );
     ^

I'm running tests for compiling the TBB to ARMv8, I saw that the build goes well, I'm using a Cortex-A53 and I'm doing all the build directly on it using a NanoPI M3.

Despite receiving some messages alerting the thumb operating instructions 32-bit blocks in IT, it seems that everything works well:

Warning: It blocks containing 32-bit Thumb instructions are deprecated in ARMv8

I want to know how is the work for adoption of the ARMv8 as another option.

Thanks

Grateful.

While running tbb under memory sanitizer.

MemorySanitizer: use-of-uninitialized-value /tbb/include/tbb/machine/gcc_ia32_common.h:79:81 in tbb::internal::cpu_ctl_env::operator!=(tbb::internal::cpu_ctl_env const&) const

    #0 0x9b1125 in tbb::internal::cpu_ctl_env::operator!=(tbb::internal::cpu_ctl_env const&) const /tbb/include/tbb/machine/gcc_ia32_common.h:79:81
    #1 0x9b1125 in tbb::internal::cpu_ctl_env_helper::set_env(tbb::task_group_context const*) /tbb/src/tbb/scheduler.h:711
    #2 0x9b1125 in tbb::internal::custom_scheduler<tbb::internal::IntelSchedulerTraits>::local_wait_for_all(tbb::task&, tbb::task*) /tbb/src/tbb/custom_scheduler.h:427
    #3 0x9a62e3 in tbb::internal::generic_scheduler::local_spawn_root_and_wait(tbb::task*, tbb::task*&) /tbb/src/tbb/scheduler.cpp:677:5
    #4 0x7b6aa6 in tbb::task::spawn_root_and_wait(tbb::task&) /tbb/include/tbb/task.h:749:30

subj. AFAIK tbb does not use CUDA anyhow, there is a suggestion here on how to workaround this issue spack/spack#6000 (comment) which might be a hint to a proper solution.

Build the project on Windows using Intel Compiler 16:
tbb/machine/msvc_ia32_common.h(69): error #1879: unimplemented pragma ignored
__TBB_MACHINE_DEFINE_ATOMICS(1,8,char,__int8)
With VC this problem isn't observed.

both task::arena::execute and task::arena::enqueue require it argument to be copyable. So following code simply wont compile:

task_arena{}.execute( 
       [p = std::unique_ptr<int>(new int)] () {
		*p = 1;
	}
); 

I take this error and i dont know what can I do. Here is my CMakeLists.txt
CMakeLists.txt

Sorry if this is not the right forum to ask this question, but it was either this forum or the Intel developer forum[1] and both seemed similarly ill-fitted for the purpose.

I had submitted a patch to enable armv8 support for libtbb with an optimization for __TBB_Pause using the documented instructions[2]. I was told that I'll get feedback in 2 business days but it has been 12 days now. Can someone from the dev team please guide me on how to get feedback and/or continue contributing to the library?

Thanks,
Siddhesh

[1] https://software.intel.com/en-us/forums/intel-threading-building-blocks
[2] https://www.threadingbuildingblocks.org/submit-contribution

It is hard to find how to enable huge pages for tbbmalloc in TBB documentation. It is mentioned very deeply in "C interface..." section of TBB allocator but not in "Environment" section to which it logically belong. Also, it does not hint how to enable huge pages on a system.

Just FYI, this info from this pdf was very helpful:

• to configure Linux for huge pages: # echo 2000 > /proc/sys/vm/nr_hugepages
• to enable huge pages for TBB malloc $ export TBB_MALLOC_USE_HUGE_PAGES=1
• for the ways to replace standard allocator see this

GitHub does not show index.html as directory description and reading index.html files is hard in plain text.
Markdown (.md) syntax is clean for direct reading (and maintaining!) and also converts easily to .html preserving all the formatting features.

E.g. online converter is here: https://pandoc.org/try/?text=&from=html&to=markdown_github

The following program:

//////////////
// main.cpp //
//////////////
#include "tbb/concurrent_unordered_set.h"

struct S
{
  int i;
  double f;

  S(int i, double f)
  : i(i)
  , f(f)
  {
  }

  bool operator==(const S &other) const
  {
    return i == other.i && f == other.f;
  }
};

namespace tbb
{

template<>
struct tbb_hash<S>
{
  size_t operator()(const S & self) const
  {
    return std::hash<int>{}(self.i) ^ std::hash<double>{}(self.f);
  }
};
}

int main()
{
  tbb::concurrent_unordered_set<MyStruct> s;
  s.emplace(0, 0.0);
}

Cannot be compiled using clang++ -std=c++11 on my x86-64 Linux Ubuntu 16.04 with the following error:

main.cpp:39:5: error: no member named 'emplace' in
      'tbb::interface5::concurrent_unordered_set<S, tbb::tbb_hash<S>,
      std::equal_to<S>, tbb::tbb_allocator<S> >'
  s.emplace(0, 0.0);

The problem persists across compiler versions (I tested the official Clang 4.0 binaries from the LLVM site and Clang 3.8 binaries from the repositories) and library versions (I tested the official 4.4-2017/06/04 and the 4.4-2015/11/15 present in the repositories).

It seems to me that some C++11 features are not correctly checked for when it comes to Clang with libstdc++. For instance, at tbb/tbb_config.h:151:

#define __TBB_CPP11_RVALUE_REF_PRESENT                  (__has_feature(__cxx_rvalue_references__) && (_LIBCPP_VERSION || __TBB_GLIBCXX_VERSION >= 40500))

The problem with this is that __TBB_GLIBCXX_VERSION is not the actual libstdc++'s version, it defaults to GCC compiler version. The problem is that Clang is only compatible with GCC-4.2.1. This means that __TBB_GLIBCXX_VERSION is stuck at 40201, even though the actual version of libstdc++ that clang uses may be high enough to enable these features. There doesn't seem to be any easy/correct way to fix this, because AFAIK there are no macros to check libstdc++'s version directly (there's __GLIBCXX__, but that's just the timestamp of when the library was built). The Boost people were having a similar problem until somebody came up with a patch that tries to determine libstdc++'s version based on #include's it offers. Could this approach be feasible for TBB?

Compiling TBB 2018_U3 with the newly-release GCC 8.1 gives this warning (sorry for the line length):

tbb/include/tbb/internal/_concurrent_unordered_impl.h:1481:24: error: 'void* memset(void*, int, size_t)' clearing an object of non-trivial type 'tbb::interface5::internal::concurrent_unordered_base<tbb::interface5::concurrent_unordered_map_traits<long unsigned int, DataDescriptor, tbb::interface5::internal::hash_compare<long unsigned int, tbb::tbb_hash<long unsigned int>, std::equal_to<long unsigned int> >, tbb::tbb_allocator<std::pair<const long unsigned int, DataDescriptor> >, false> >::raw_iterator' {aka 'class tbb::interface5::internal::flist_iterator<tbb::interface5::internal::split_ordered_list<std::pair<const long unsigned int, DataDescriptor>, tbb::tbb_allocator<std::pair<const long unsigned int, DataDescriptor> > >, std::pair<const long unsigned int, DataDescriptor> >'};
    use assignment or value-initialization instead [-Werror=class-memaccess]
             std::memset(new_segment, 0, sz*sizeof(raw_iterator));
             ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tbb/include/tbb/internal/_concurrent_unordered_impl.h:71:7: note: 'tbb::interface5::internal::concurrent_unordered_base<tbb::interface5::concurrent_unordered_map_traits<long unsigned int, DataDescriptor, tbb::interface5::internal::hash_compare<long unsigned int, tbb::tbb_hash<long unsigned int>, std::equal_to<long unsigned int> >, tbb::tbb_allocator<std::pair<const long unsigned int, DataDescriptor> >, false> >::raw_iterator' {aka 'class tbb::interface5::internal::flist_iterator<tbb::interface5::internal::split_ordered_list<std::pair<const long unsigned int, DataDescriptor>, tbb::tbb_allocator<std::pair<const long unsigned int, DataDescriptor> > >, std::pair<const long unsigned int, DataDescriptor> >'}
    declared here
 class flist_iterator : public std::iterator<std::forward_iterator_tag, Value>
       ^~~~~~~~~~~~~~

I patched it locally to resolve this with:

--- a/include/tbb/internal/_concurrent_unordered_impl.h 2018-05-13 13:05:19.888005000 -0400
+++ b/include/tbb/internal/_concurrent_unordered_impl.h 2018-05-13 13:30:31.724891533 -0400
@@ -1468,7 +1468,7 @@
         if (my_buckets[segment] == NULL) {
             size_type sz = segment_size(segment);
             raw_iterator * new_segment = my_allocator.allocate(sz);
-            std::memset(new_segment, 0, sz*sizeof(raw_iterator));
+            std::memset(static_cast<void*>(new_segment), 0, sz*sizeof(raw_iterator));
 
             if (my_buckets[segment].compare_and_swap( new_segment, NULL) != NULL)
                 my_allocator.deallocate(new_segment, sz);

Note there may be other similar errors I didn't check all the code.

The file include\tbb\internal\_tbb_windef.h uses the _WIN32_WINNT macro to ensure that the Windows version supports TBB. See lines 25-29:

// Check that the target Windows version has all API calls requried for TBB.
// Do not increase the version in condition beyond 0x0500 without prior discussion!
#if defined(_WIN32_WINNT) && _WIN32_WINNT<0x0501
#error TBB is unable to run on old Windows versions; _WIN32_WINNT must be 0x0501 or greater.
#endif

Macros for specific versions of Windows are defined in SDKDDKVer.h, see Using the Windows headers.
It is recommended to use the macros instead of the specific Windows version numbers, e.g.:

#define _WIN32_WINNT _WIN32_WINNT_WINXP

instead of:

#define _WIN32_WINNT 0x0501

Also, some libraries require a Windows macro and not a Windows version number.
However, this causes the tbb build to fail and line 28 of include\tbb\internal\_tbb_windef.h to be output.

It would be good for tbb to support the standard macros as well as the Windows version numbers.

Note: MSVC 2017 no longer supports Windows versions older than XP, see: Modifying WINVER and _WIN32_WINNT.

See discussion at #2 (comment)

The generic backend for machine instructions in tbb/include/tbb/machine/gcc_generic.h does not provide __TBB_Pause implementation, which results in the emulation from tbb/include/tbb/tbb_machine.h to be used. This is a regression compared to the specialized backends like linux_ia32.h and linux_intel64.h which use the implementation from gcc_ia32_common.h.

The gcc_generic.h backend is used with pretty much any modern gcc-compatible compiler nowdays, so the regression is quite unfortunate. The generic backend should still use the architecture-specific implementation of __TBB_Pause (i.e. if the target is x86 then it should employ the pause instruction).

I installed the tbb from source code. Run gmake occurs below error.
CentOS release 6.5 (Final), gcc 4.9.2

/tmp/ccK2bNjL.s: Assembler messages:
/tmp/ccK2bNjL.s:615: Error: no such instruction: xtest' /tmp/ccK2bNjL.s:634: Error: no such instruction: xend'
/tmp/ccK2bNjL.s:801: Error: no such instruction: xbegin .L54' /tmp/ccK2bNjL.s:817: Error: no such instruction: xabort $255'
/tmp/ccK2bNjL.s:972: Error: no such instruction: xbegin .L70' /tmp/ccK2bNjL.s:990: Error: no such instruction: xabort $255'
gmake[1]: *** [x86_rtm_rw_mutex.o] Error 1
gmake[1]: Leaving directory `/export/servers/gcc/tbb-2017_U5/build/linux_intel64_gcc_cc4.9.2_libc2.12_kernel2.6.32_debug'
gmake: *** [tbb] Error 2

__TBB_ASSERT_RELEASE as defined in tbb_stddef.h uses the __FILE__ macro regardless of the build type, generating binaries that contain the full path of the file invoking the macro at compile time, which may contain user information.

The way the version_info.ver file is generated by passing the full compiler command line also generates full paths that are embedded into the final binaries, regardless whether the library is build as a dynamic library or linked statically against another executable.

src/tbb/private_server.cpp currently tries to include thread_monitor.h via
#include "../server/thread_monitor.h"

This only works because the include paths are adjusted, whereas all other files attempt to include rml files by specifying the full relative path, e.g. src/tbb/governor.h: #include "../rml/include/rml_tbb.h".

This behaviour creates problems when writing build scripts for e.g. bazel and I think is a mistake/bug. Could this be fixed in the next update?

Thanks!

Please refer to DynamoRIO/drmemory#2004 for a detailed description.

The errors are reported for memory addresses returned by task::prefix() method (usually within constructors for the task class).

Will appreciate your opinion on whether these are likely to be false positives reported by Dr. Memory, or if this is indeed an issue within TBB.

Thanks!

Running make CXXFLAGS=-std=c++17, results in the following error:

g++ -c -MMD -DTBB_USE_DEBUG -DDO_ITT_NOTIFY -g -O0 -DUSE_PTHREAD -m64 -mrtm  -Wall -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -Wno-parentheses -Wno-non-virtual-dtor -fPIC  -D__TBBMALLOC_BUILD=1 -I../../src -I../../src/rml/include -I../../include -I../../src/tbbmalloc -I../../src/tbbmalloc ../../src/tbbmalloc/proxy.cpp

../../src/tbbmalloc/proxy.cpp:234:32: error: ISO C++1z does not allow dynamic exception specifications
 void * operator new(size_t sz) throw (std::bad_alloc) {
                                ^~~~~
../../src/tbbmalloc/proxy.cpp:242:33: error: ISO C++1z does not allow dynamic exception specifications
 void* operator new[](size_t sz) throw (std::bad_alloc) {
                                 ^~~~~

A recent Debian test with GCC7 failed with the TBB compilation error

/usr/include/tbb/pipeline.h:328:74: error: 'has_trivial_copy_constructor' is not a member of 'std'

(Coming from
https://github.com/01org/tbb/blob/a602c7dd54ca5e1d6b5a6b8e3289f0f70fc466a9/include/tbb/pipeline.h#L326.)

The build fails with the message "Intel TBB can not be built: required make-tool (gmake) was not found".

TDM-GCC comes with mingw32-make, instead of gmake.

TBB version: Commit: eb6336a [eb6336a] (Committing Intel(R) TBB 2017 Update 7)

tbb/_build/tbb-tbb_2017/include/tbb/tbb_machine.h: In function 'intptr_t TBB_Log2(uintptr_t)':
tbb/build/tbb-tbb_2017/include/tbb/tbb_machine.h:862:61: error: 'tmp' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if( sizeof(x)>4 && (tmp = ((uint64_t)x)>>32) ) { x=tmp; result += 32; }

arm-linux-gnueabihf-g++ -o pipeline.o -c -MMD -DTBB_USE_DEBUG -g -O0 -DUSE_PTHREAD -Wa,-mimplicit-it=thumb -fPIC -D__TBB_BUILD=1 -Wall -Wno-parentheses -Wno-non-virtual-dtor -Wall -Wno-reorder -Wno-unknown-pragmas -MMD -fPIC -std=c++98 -Werror -ggdb -fno-inline -fno-omit-frame-pointer -D__TBB_DYNAMIC_LOAD_ENABLED=0 -D__TBB_SOURCE_DIRECTLY_INCLUDED=1

tbb_machine.h:
inline intptr_t __TBB_Log2( uintptr_t x ) {
if( x==0 ) return -1;
intptr_t result = 0;

#if !defined(M_ARM)
uintptr_t tmp;
if( sizeof(x)>4 && (tmp_ = ((uint64_t)x)>>32) ) { x=tmp_; result += 32; }
#endif
if( uintptr_t tmp = x>>16 ) { x=tmp; result += 16; }
if( uintptr_t tmp = x>>8 ) { x=tmp; result += 8; }
if( uintptr_t tmp = x>>4 ) { x=tmp; result += 4; }
if( uintptr_t tmp = x>>2 ) { x=tmp; result += 2; }

return (x&2)? result+1: result;

}

Is it applicable only for _M_ARM? or for arm too?

Statically linking with gcc on OS X can cause TBB to segfault.

This simple program segfaults when TBB is built with GCC 7.3 and linked in statically.

#include <tbb/task_scheduler_init.h>
#include <iostream>
#include <cstdlib>
#include "a.pb.h"

using namespace tbb;

int main(int argc, char* argv[]) {
  A a;
  tbb::task_scheduler_init tbb_init{};
  std::cout << a.DebugString() << "\n";
  return 0;
}

Note: that it works if protobuf isn't linked in.

I posted here and included the coredump, exectuable, and a bazel build that can reproduce the issue.

This is the backtrace from the crash:

(lldb) bt
* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x000000010bc12dc9 fib`tbb::internal::governor::sign_off(tbb::internal::generic_scheduler*) + 41
    frame #1: 0x000000010bc17fb8 fib`tbb::internal::generic_scheduler::free_scheduler() + 152
    frame #2: 0x000000010bc18686 fib`tbb::internal::generic_scheduler::cleanup_master(bool) + 438
    frame #3: 0x000000010bc0ebb4 fib`tbb::task_scheduler_init::~task_scheduler_init() + 36
    frame #4: 0x000000010bc0ec5a fib`main + 151
    frame #5: 0x00007fff9f426235 libdyld.dylib`start + 1
    frame #6: 0x00007fff9f426235 libdyld.dylib`start + 1

From here https://www.threadingbuildingblocks.org/docs/help/reference/task_groups/task_group_cls/task_group_cls_members.html :

Return type in the description (bool) conflict with one in signature (task_group_status)

Ey guys, it seems the SSL certificate of the website expired last night.

Is there possibly an issue with the release process? It seems that release 2017_U5.tar.gz was recreated. SHA-256 is now 3122c87a35fde759567c8579ba36a36037c6df84c3f9c4df6c9e171f866f352f whereas it used to be 780baf0ad520f23b54dd20dc97bf5aae4bc562019e0a70f53bfc4c1afec6e545 as recent as Sep 5, 2017. The content has not changed.

Traces on the web of the previous hash (there are more):

• https://github.com/Homebrew/homebrew-core/pull/10569/files
• https://bugs.freebsd.org/bugzilla/attachment.cgi?id=185609&action=edit

Hi,

Trying to build tbb with CC and CXX specified as absolute paths lead to errors, see that PR on FreeBSD :

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215656

Could you have a look at the following patch and maybe integrate it upstream ? :

https://svnweb.freebsd.org/ports/head/devel/tbb/files/patch-common.inc?view=co

Thanks !

In tbb/include/tbb/machine/linux_common.h, wait and wakeup futex operations are defined in terms of FUTEX_WAIT and FUTEX_WAKE. These operations are targeted for process-shared futexes. Since TBB is not supposed to operate on process-shared futexes, these operations should be relaxed to FUTEX_WAIT_PRIVATE and FUTEX_WAKE_PRIVATE, respectively.

Note that there were (old) Linux kernels that supported FUTEX_WAIT and FUTEX_WAKE but not their *_PRIVATE counterparts. You will probably need to test whether the *_PRIVATE macro is defined first, and then the rest. I.e. something like this:

#if defined(FUTEX_WAIT_PRIVATE)
#define __TBB_FUTEX_WAIT FUTEX_WAIT_PRIVATE
#elif defined(FUTEX_WAIT)
#define __TBB_FUTEX_WAIT FUTEX_WAIT
#else
#define __TBB_FUTEX_WAIT 0
#endif

The news section of https://www.threadingbuildingblocks.org/news-archive includes the following text for each recent release:

Files are available on the release page of the Github reposiotry.

"reposiotry" is not a word. This should be fixed to read:

Files are available on the release page of the Github repository.

It would be useful to have an aligned version of blocked_range:

template< typename Iterator, std::size_t Alignment >
class aligned_blocked_range;

The idea is that the aligned_blocked_range should divide the range on boundaries that are a multiple of Alignment from the beginning of the range. It should still provide support for grain size, which should be not less than Alignment and should be rounded up to the nearest multiple of Alignment. The range is splittable if its size is at least 2 grain sizes (i.e. the split must never produce a range that is less than Alignment).

The existing blocked_range doesn't provide that guarantee because even if you specify an aligned grain size because it will split the range in halves and thus will lose alignment if the range size is not exactly an even multiple of the grain size. Also, the current blocked_range split can produce a range that is less than the grain size.

The aligned_blocked_range is useful when the input range is already aligned, and threaded processing should also preferably be aligned. For example, in image processing, the image rows might be cache line aligned, and each chunk of row suitable for threaded processing should also be aligned to a cache line to avoid false sharing effects.

https://github.com/01org/tbb/archive/2018_U3.tar.gz

On the 31/03 the sha256 was a0be619c741ee399de740ee7192c41a92fbbc7a8f3bda3032d6d6167e13f9dac

Currently the sha256 is 23793c8645480148e9559df96b386b780f92194c80120acce79fcdaae0d81f45

We need to confirm that the checksum change is legitimate before we can update the Homebrew formula.

Seems that even with the recent change https://github.com/01org/tbb/blob/tbb_2017/build/linux.inc#L102 the s390x architecture is still considered as 32-bit (not understood as 64-bit). We have used http://pkgs.fedoraproject.org/cgit/rpms/tbb.git/tree/tbb-2017-64bit.patch?id=487f57941428c310003d531c3bad6ed22075824a to fix that.

The Fedora s390x build of tbb is available at https://s390.koji.fedoraproject.org/koji/buildinfo?buildID=444404 and if you inspect the build.log in the "Build logs" link, you will see that lin32-tbb-export.def is used, which is wrong.

I used tbb/compat/condition_variable in order to make source code backward-compatible with old compilers.
However, I had to write the following instead of just including single compat file:

#include <tbb/tbb.h>
#include <tbb/compat/condition_variable>
#if TBB_IMPLEMENT_CPP0X
namespace std { using tbb::mutex; }
#define unique_ptr auto_ptr
#else
#include <condition_variable>
#include <mutex>
#include <memory>
#endif

So, at least, current implementation misses namespace std { using tbb::mutex; } part. Ideally, I want to complete story by being forward compatible automatically. I.e. when the backward-compatible code is being compiled by new compiler, it should just switch to all the standard implementations without additional effort.

For reasons unbeknownst to me, interacting with the concurrent_hash_map with a const_accessor during iteration, appears to cause the iterator to skip and repeat certain elements.

Minimal working example (compiled with g++ 7.2.0):

#include <iostream>
#include <memory>
#include <tbb/concurrent_hash_map.h>

int main() {
    typedef tbb::concurrent_hash_map<size_t, size_t> mappi;
    mappi x;

    constexpr size_t kkk = 1000000;
    for (size_t i = 0; i < kkk; ++i) {
        typename mappi::accessor a;
        x.insert(a, i);
        a->second = i;
    }

    // count that is spuriously too much
    size_t count = 0;
    for (auto& o : x) {
        typename mappi::const_accessor a;
        x.find(a, o.first);
        ++count;
    }

    std::cout << x.size() << std::endl; // outputs 1000000
    std::cout << count << std::endl; // outputs 1262143 (!!) 

    // regular correct count
    count = 0;
    for (auto& o : x) {
        ++count;
    }

    std::cout << x.size() << std::endl; // outputs 1000000
    std::cout << count << std::endl; // outputs 1000000

    return 0;
}

Produces output as described by the comments.

From what I can tell from the documentation, this is not correct behaviour.

The zip for Windows has been reissued (judging by the md5sum) but the Android version is still defective.
"invalid compressed data--crc error
invalid compressed data--length error"

last file delivered: internal/_flow_graph_join_impl.h