{5} Assigned, Active Tickets by Owner (Full Description) (203 matches)

The "geometry distance matrix" indicates that all geometry-to-geometry distances have been implemented in 1.57. But the box-to-box distance doesn't seem to work with spherical geometries, at least with gcc 4.4.7.

One of the errors seems to be a "not yet implemented" error, so perhaps it hasn't been done yet. It does have some tricky business that a cartesian box wouldn't have, but it's a straightforward exercise in trying different cases.

I'm certainly delighted with boost::geometry's functionality as is, but it would be great if this worked. And many apologies if the mistake is mine.

See example below for problem.

#include <boost/geometry/geometry.hpp>

typedef boost::geometry::model::point<double,2,boost::geometry::cs::cartesian> cartesian_point;
typedef boost::geometry::model::point<double,2,boost::geometry::cs::spherical_equatorial<boost::geometry::degree> > spherical_point;

int main()
{

  // Works...
  boost::geometry::model::box<cartesian_point> c_box1, c_box2;
  boost::geometry::distance(c_box1,c_box2);

  // Doesn't work!
  boost::geometry::model::box<spherical_point> s_box1, s_box2;
  boost::geometry::distance(s_box1,s_box2);

  return 0;
}

Consider the following C++11 code, adapted from the Range documentation:

std::vector<int> vec;
for (int val : vec | boost::adaptors::reversed
                   | boost::adaptors::uniqued) {
  // Do stuff with val
}

The behavior of this natural-seeming code is actually undefined, due to a dangling reference: per the C++ standard, it is equivalent to

{
  auto && __range = (vec | boost::adaptors::reversed
                         | boost::adaptors::uniqued);
  for ( auto __begin = __range.begin(),
             __end = __range.end();
        __begin != __end;
        ++__begin ) {
    int val = *__begin;
    // Do stuff with val
  }
}

The problem is that the value returned by the subexpression vec | boost::adaptors::reversed is a temporary, so its lifetime ends at the end of the statement containing it, namely the declaration of __range. Thus, __range is left holding a dangling reference to the range it's adapting.

The fix is for each range adaptor to use an rvalue-reference overload to detect whether the input range is a temporary, and if so, move it into the adaptor (i.e. with std::move) in order to extend its lifetime.

The »indexed« range adaptor has changed in v1.56.0 in source-breaking ways. I get the change and that it was necessary for range-based for loops, but this means that you now have to #if BOOST_VERSION < … around it. See ​this example (distilled from actual code).

Why the ticket? Because the change hasn't been mentioned at all in the release notes.

Since 1.56, when dereferencing, any_range tries to use static cast of reference instead of implicit conversion like in 1.55.

Here is an example that works with 1.55 but fails to compile with 1.56.

#include <boost/range/any_range.hpp>
#include <memory>
#include <vector>

struct A {};

int main() {
    std::vector<std::shared_ptr<A> > v;
    boost::any_range<std::shared_ptr<const A>,
                     boost::forward_traversal_tag,
                     std::shared_ptr<const A>,
                     std::ptrdiff_t> r(v);
}

This came up in tracking down unit-test failures when trying to build a project with newer compiler versions with C++11 enabled. The unit-test in question was compiled with multiple compiler versions:

• gcc 4.3.4 (without C++11 enabled): working at all optimization levels
• gcc 4.7.2 (with C++11 enabled): works without optimizations, failed with -O1 or higher
• gcc 4.8.4 (with C++11 enabled): works without optimizations, failed with -O1 or higher
• clang 3.5.0 (recent build, with C++11 enabled): works at all optimization levels

The failure was tracked down to a use of boost::range::joined_range (Boost 1.55.0), effectively declared as:

boost::range::joined_range<boost::iterator_range<std::vector<char>::iterator, boost::iterator_range<const char*>>

In this form, the joined_range created from two valid ranges winds up "somewhere else" when the higher optimization level. I've attached a test case that demonstrates the problem. Compiled with:

g++ -std=c++11 -o join_bug join_bug.cpp

works (printing out the expected ASCII values of the joined ranges). Compiled with:

g++ -O1 -std=c++11 -o join_bug join_bug.cpp

fails (printing out zero's in my test, though the correct number of them). This test was run with the same compiler versions as above, on both Boost 1.54.0 and Boost 1.55.0, as well as gcc 4.8.2 and clang 3.4 (both for Ubuntu 14.04), with a slightly modified non-C++11 version for the gcc 4.3.4 compiler, all with the same successes/failures.

The problem goes away in all tests if the joined_range is declared like so (changing from std::vector<char>::iterator to std::vector<char>::const_iterator):

boost::range::joined_range<boost::iterator_range<std::vector<char>::const_iterator, boost::iterator_range<const char*>>

I realize this might be a gcc bug, rather than a Boost bug, but I haven't seen this reported elsewhere and would like to get the behaviour tracked since I'm only seeing problems in relation to joined_range...

This must be related to #10360. This is a regression since 1.55.

When using any_range<T, category, T, ptrdiff_t>, mutable dereference() method returns mutable_reference_type_generator<T>::type, which becomes T&. So dereference() returns a dangling reference to an on-the-fly computed value.

See attached test case, which works with 1.55, and fails with -fsanitize=address on Clang 3.5 with 1.56.

#include <boost/range/any_range.hpp>
#include <boost/range/adaptor/transformed.hpp>
#include <cmath>
#include <iostream>

typedef boost::any_range<
    std::string,
    boost::forward_traversal_tag,
    std::string,
    std::ptrdiff_t
> range_t;

std::string f(std::string a)
{
    return a + "!";
}

int main()
{
    std::vector<std::string> v = {"a", "b"};
    range_t r = v | boost::adaptors::transformed(f);
    for (auto&& a : r)
        std::cout << a << std::endl;
    return 0;
}

The attached code compiles with GCC 4.9.2 and MSVC 2013, but fails with Clang 3.5.0. I've first reported it against clang, but they explained that it's actually incorrect in Boost, see clang bug #21787 (the bugtracker rejects links here).

From ​http://stackoverflow.com/questions/28280553/boostadaptorsstrided-cannot-be-used-after-boostadaptorstransformed

[...]/boost/1.57.0/include/boost/range/iterator_range_core.hpp:216:20: error: no matching function for call to ‘boost::range_detail::strided_iterator<boost::iterators::transform_iterator<TrivialTrafo, __gnu_cxx::__normal_iterator<int*, std::vector<int> >, boost::iterators::use_default, boost::iterators::use_default>, boost::iterators::detail::iterator_category_with_traversal<std::input_iterator_tag, boost::iterators::random_access_traversal_tag> >::strided_iterator(boost::range_detail::strided_iterator<boost::iterators::transform_iterator<TrivialTrafo, __gnu_cxx::__normal_iterator<int*, std::vector<int> >, boost::iterators::use_default, boost::iterators::use_default>, boost::iterators::random_access_traversal_tag>&)’

, m_End(End)

Problem is that make_begin_strided_iterator et al coerce the returned iterator traversal category/tag to a pure traversal tag, which doesn't necessarily agree with the Category passed to iterator_range for the base type. Fix is to use iterators::pure_iterator_traversal.

The Graph library uses std::pair to pass ranges and this allows a nice pattern to use old-fashioned for-loops:

Graph g; boost::graph_traits<Graph>::vertex_iterator b, e; for(boost::tie(b, e) = vertices(g); b != e; ++b) {

}

This works without any modifications with pair.

The functionality would be great for all ranges as it provides users that don't want to use Boost.Range algorithms with a simple way to use their preferred style or algorithms from std.

http://www.boost.org/doc/libs/1_40_0/libs/ptr_container/doc/ptr_vector.html#c-array-support

is it possible to remove non-null requirement for from argument in ptr_vector::transfer method?

The 'put' helper function in the boost property map library should support move semantics. At the moment it takes the value to be put by const reference, I think it would be more appropriate to perfect forward it.

We've discovered an issue Boost has writing and reading wide character strings (wchar_t* and std::wstrings) to non-wide character file streams (std::ifstream and std::ofstream). The issue stems from the fact that wide characters are written and read as a sequence of characters (in text_oarchive_impl.ipp and text_iarchive_impl.ipp, respectively). For text streams, an EOF character terminates the reading of a file on Windows. Some wide characters have EOF (value = 26 decimal) as one of the bytes so reading that byte causes early termination of the read. We have worked around the issue by deriving our own input and output archives from text_i|oarchive_impl<Archive> and overriding load_override() and save_override for std::wstring and wchar_t*. Our implementation just sequences through the wide characters and writes them 1 by 1 as wchar_t to the archive. This isn't very elegant and is even less readable in the file than the current implementation but does resolve the problem.

Although the test test_simple_class does test wstrings, it only uses characters 'a'-'z' which does not expose this problem.

MSVS 2008 The code:

#include "boost/archive/iterators/base64_from_binary.hpp"
#include "boost/archive/iterators/binary_from_base64.hpp"
#include "boost/archive/iterators/transform_width.hpp"

//typedefs
typedef  std::istreambuf_iterator<char>    my_istream_iterator;
typedef  std::ostreambuf_iterator<char>    my_ostream_iterator;

typedef boost::archive::iterators::base64_from_binary<
          boost::archive::iterators::transform_width< my_istream_iterator, 6, 8>
> bin_to_base64;

typedef boost::archive::iterators::transform_width<
    boost::archive::iterators::binary_from_base64< my_istream_iterator >, 8, 6
> base64_to_bin;

void test()
{
   {
        //INPUT FILE!!!
    std::ifstream ifs("test.zip", std::ios_base::in|std::ios_base::binary);
    std::ofstream ofs("test.arc", std::ios_base::out|std::ios_base::binary);

    std::copy(
        bin_to_base64( my_istream_iterator(ifs >> std::noskipws) ),
        bin_to_base64( my_istream_iterator() ),
        my_ostream_iterator(ofs)
    );
  }

  {
    std::ifstream ifs("test.arc", std::ios_base::in|std::ios_base::binary);
    std::ofstream ofs("test.rez", std::ios_base::out|std::ios_base::binary);

    std::copy(
        base64_to_bin( my_istream_iterator(ifs >> std::noskipws) ),
        base64_to_bin( my_istream_iterator() ),
        my_ostream_iterator(ofs)
    );
  }
}

Result: 1) If the INPUT FILE will be any of ZIP-file format. The result was:

a) _DEBUG_ERROR("istreambuf_iterator is not dereferencable"); it can be disabled or ignored b) The encoded file "test.rez" will have one superfluous byte than INPUT FILE

2) If the INPUT FILE will any other file (binary or text) all will be OK.

Serializing a vector<bool> causes corruptions in the created archive. The reason is this function (in boost/serialization/vector.hpp):

template<class Archive, class U, class Allocator>
inline void save(
    Archive & ar,
    const std::vector<U, Allocator> &t,
    const unsigned int /* file_version */,
    mpl::true_
){
    const collection_size_type count(t.size());
    ar << BOOST_SERIALIZATION_NVP(count);
    if (!t.empty())
        ar << make_array(detail::get_data(t),t.size());
}

While detail::get_data(t) is not specialized for std::vector<bool> (but it should be), and t.size() returns the number of bits stored in the vector, which is probably not what's expected either.

I'm encountering this problem with MSVC10, 64bit, Windows7.

Using afl-fuzz on some simple programs that use boost binary and xml serialization, I have found a number of crashes and assertion failures.

To test the waters, I am beginning by filing a single bug which may allow a jump to an attacker-controlled address (i.e., the most exploitable-looking crash that has turned up so far). On my test system, it crashes on the instruction shown:

=> 0x000000000044849c <+524>:   mov    (%r12),%rax
   0x00000000004484a0 <+528>:   mov    0x20(%rbp),%r15d
   0x00000000004484a4 <+532>:   mov    %r12,%rdi
   0x00000000004484a7 <+535>:   callq  *0x10(%rax)

Notice that the value loaded at instruction <+524> is used to determine the address to call at instruction <+535>. The value of %r12 interpreted as bytes is "\0\0hive\0\0", which makes me strongly suspect that it is data from the input file (part of the 'serialization::archive' signature, masked off). Generally, the whole text of the input file would be considered under the control of the adversary.

I ran my tests on Debian Jessie amd64 with gcc version 4.9.2 (Debian 4.9.2-10). The following revisions of modularized boost were used (the tip of each master branch at the time of writing, as described by 'git describe --tags --always):

config: boost-1.62.0-57-g1abc59c
core: boost-1.61.0-59-gd753d9a
move: boost-1.63.0
serialization: boost-1.61.0-57-g62bf8fc

The commandline to compile the (non-fuzzing) version of the input test program is:

g++-4.9 -std=c++11 -Os -I serialization/include -I core/include -I move/include -I config/include -o pvec_in pvec_in.cc serialization/src/extended_type_info.cpp serialization/src/extended_type_info_typeid.cpp serialization/src/archive_exception.cpp serialization/src/basic_archive.cpp serialization/src/basic_serializer_map.cpp serialization/src/void_cast.cpp serialization/src/singleton.cpp serialization/src/basic_iarchive.cpp serialization/src/binary_iarchive.cpp serialization/src/basic_iserializer.cpp serialization/src/basic_pointer_iserializer.cpp

The breaking input file is (base-64 encoded):

FgAAAAAAAABzZXJpYWxpemF0aW9uOjphcmNoaXZlDwAECAQIAQAAAAAAAAAAAwAAAAAAAAABAAAA
AAEAAAD0/wEAAAAAAAAAAAEAAAACAAEAAAACAAAAAgAAAAAA

The source for the test harness program (pvec_in.cc) is

#include <fstream>
#include <vector>

#include <boost/shared_ptr.hpp>
#include <boost/archive/binary_iarchive.hpp>
#include <boost/serialization/nvp.hpp>
#include <boost/serialization/shared_ptr.hpp>
#include <boost/serialization/vector.hpp>

struct boxed_int
{
    boxed_int() : i(0) {}
    boxed_int(int i) : i(i) {}
    int i;
    template<class Archive>
    void serialize(Archive &ar, unsigned version)
    {
        ar & BOOST_SERIALIZATION_NVP(i);
    }
};
typedef boost::shared_ptr<boxed_int> pi;

void go(std::istream &is) {
    std::vector<pi> vv;
    try
    {
        boost::archive::binary_iarchive ia(is);
        ia & vv;
    }
    catch(std::exception &e) {}
}

int main(int argc, char **argv) {
    if(argc > 1) {
        std::ifstream is(argv[1]);
        go(is);
    } else {
        go(std::cin);
    }

    return 0;
}

The test harness program either takes the input file on stdin or the name of the input file as the first positional argument.

I can share details about the fuzzing setup if you like.

Thank you for taking the time to consider this issue.

--Jeff

Like the summary says, I think boost/test/impl/framework.ipp should simply have one additional #include <boost/bind/placeholders.hpp> so it works when BOOST_BIND_NO_PLACEHOLDERS is defined.

there is a tutorial about new boost test feature - the labels. but it is not clear how to run all tests in testsuite except those that are with a specific label. could you help, please?

Hi,

I've been trying hard, but it is annoying, didn't find it elsewhere and it could really be improved.

I am building my project (i.e. all of my project tree)

on 2 platforms:

• Windows,
• Linux,

for 3 different platforms:

• Windows
• Linux IA32
• Linux ARM HF

Now, whilst b2 subsystem is quite flexible in specifying different types of compilers, it is not so much when using the same type of compiler, but using different versions of it.

I have managed to define it somehow, i.e. in my project_config.jam (@ home dir):

if [ os.name ] = NT
{
using gcc : : :
     <cxxflags>-std=c++11 
     <cxxflags>"-include cmath"
     <cxxflags>-Wdeprecated-declarations
    ;

using gcc : armhf : arm-linux-gnueabihf-g++.exe :
     <cxxflags>-std=c++11
     <cxxflags>"-include cmath"
     <cxxflags>-Wdeprecated-declarations
    ;
}

if [ os.name ] = LINUX
{
using gcc : : :
     <cxxflags>-std=c++11 
     <cxxflags>"-include cmath"
    ;

using gcc : armhf : /usr/bin/arm-linux-gnueabihf-g++ :
     <cxxflags>-std=c++11 
     <cxxflags>"-include cmath"
     <cxxflags>-Wdeprecated-declarations
    ;
}

But now, in every sub-project, where I'm moving files to a 'release' location, (* and whenever I need to specify copmiler-flavor specific configuration) I need to perform something like:

install copy_binaries_to_release
  : 
    target_names..
  :
    <target-os>linux:<toolset-gcc:version>4.7:<location>../../release/
    <target-os>windows:<toolset>gcc-4.7.2-mingw:<location>../../release/
    <toolset-gcc:version>armhf:<location>../../release_armhf/
    <toolset>gcc-mingw-armhf:<location>../../release/
  ;

Is there a better way of doing it?

If not, then the problem (and I guess a bug) is that b2 behaves differently on different platforms, somewhat lacks of mechanism to support what I need to do (and it's not really very uncommon).

Problems:

1. Different toolset names when building on different OSes (and yes, I did try to specify a default flavor, but see Problem 2).

Only gcc-armhf seems to achieve requested results. BUt the main issue it, that it is all different on different platforms, and both: armhf should produce compatible binaries.

BTW: is there really a need to distinguish between e.g. Cygwin and MinGW flavours if they produce the same target with the same version of compiler? If one builds from Cygwin and MinGW for the same platform: resulting executables should be compatible for the same target, so only in 'bin' build directory they can really be different (if needed), but it is unlikely that one builds both of them (target:gcc version) at the same time (like it is unlikely that I build under windows and linux at the same time).

2. It is not possible to specify a flavor for GCC (by explicitly giving it a name and compiler location) - because b2 is performing a version check. This check either fails, or if it does not (and default version is used) - automatic build-platform-specific flavor value is created behind the control) - probably because b2 is trying to be too clever at this.

Couldn't it leave it alone, and use flavor that was explicitly specified?

I really wish that I could specify above:

using gcc : 4.7 : <my-path-to-gcc47> ... ;
using gcc : armhf : <my-path-to-gcc47 arm hf>  ... ;

and wouldn't have to create links or worry about the build system changing/ coming up with a flavor by concatenating target name (e.g. on

b2 --toolset=gcc-armhf

with g++ (and having to hack/create symlinks to match this etc.) -

It should just accept what I specify, and use it 'as-is' (and if someone does something stupid - let them fail and fix it).

There could also be a support for something like:

import toolset ;

if [ toolset.name ] == gcc
{
  if [ toolset.flavor ] == flav_1
  {
  }
}

# and my verbosive Jamfiles could be re-written to something like:

local gcc_flavor = [ toolset.flavor ] ;
install copy_binaries_to_release
  : 
    target_names..
  :
    <toolset>gcc,<flavor>4.7:<location>../../release
    <toolset>gcc,<flavor>armhf:<location>../../release_$(gcc_flavor)
    
    # or even to:
    <toolset>gcc:<location>../../release_$(gcc_flavor)
  ;

With a bit of guidance / advice from someone, who knows the build system well - I'm happy to help with implementing the above.

Thanks, LUkasz.

(BTW: what is the best component for build system / tools?)

To make result_of and tr1_result_of equivalent, we have to add specialization of tr1_result_of. (Boost.Phoenix V3 already has specialization of result_of.)

Also, it would be nice to avoid specialization of result_of, when we use decltype-based result_of. (As for tr1_result_of, it should be specialized even when decltype-based result_of is used.)

So, instead of

template <...>
struct result_of<F()>
{
    typedef XXXX type;
};

we should write

#if !defined(BOOST_RESULT_OF_USE_DECLTYPE) || defined(BOOST_NO_DECLTYPE)
template <...>
struct result_of<F()>
{
    typedef XXXX type;
};
#endif

template <...>
struct tr1_result_of<F()>
{
    typedef XXXX type;
};

A quick grep said the following files specialize result_of.

• phoenix/core/actor.hpp
• phoenix/function/function.hpp

I noticed that if you try to traverse more than once the range (begin,end) obtained with the stl_input_iterator, you don't get the expected results.

Please, look at the attached code (rangemodule.cpp) and at the usage from the python console (python_console.txt).

The problem is given by the call to the std::distance function.
If you build with -DWORK_AROUND the problem disappears, but I need to call std::distance, because it is the original class that calls it (and I prefer not to modify it simply for building a python extension).

I've successfully built and installed boost.MPI and the Python bindings in my home dir.

Unfortunately, the Python module "mpi.so" is installed directly in the lib/-path as all the other Boost libs. When setting the PYTHONPATH to point to this location, the boost.mpi python bindings are accessible only via "import mpi" from within Python, and not via "import boost.mpi", as described in the docs at

http://www.boost.org/doc/libs/1_38_0/doc/html/mpi/python.html

I think that the Python modules should go to a sudirectory "boost" in the lib path, or it should be fixed in the documentation.

Otherwise, the boost.mpi Python bindings are gorgeous!

When a filtering_stream with a gzip_compressor is used to write to a full hard drive (i.e. insufficient free space), boost enters an infinite loop in /boost/iostreams/detail/adapter/non_blocking_adapter.hpp:41 because the write function keeps returning zero. This loop happens during the destruction of the stream. I can't seem to find a client-side workaround.

Attached is a test case, point it to a volume with zero space and give some large number of bytes. If there's insufficient space, execution hangs. Tested on mingw/winxp/gcc4.2 but seems to fail on linux/gcc as well.

As I understood from the trac ticket ​https://svn.boost.org/trac/boost/ticket/7089 and sources for boost 1.50, boost::thread 1.50 implicitly adds 100 ms to the sleep time of boost::this_thread::sleep and boost::thread_sleep on linux. If the fix for 7089 cannot be backported into 1.50, the warning about broken functionality must be present in the documentation for 1.50.

Test output: BenPope x86_64 Ubuntu - thread - notify_all_at_thread_exit_p / clang-linux-3.6~tsan~c14_libc++
Rev 9b68e2eec037cbcb6f96d7d54079e7e1a6a274ab / Mon, 09 Mar 2015 11:14:53 +0000
Compile [2015-03-09 15:31:08 UTC]: succeed


"clang++-3.6" -c -x c++ -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -std=c++1y -stdlib=libc++ -fsanitize=thread -O0 -fno-inline -Wall -pthread -fPIC -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -o "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o" "../libs/thread/test/sync/conditions/notify_all_at_thread_exit_pass.cpp"

            

Link [2015-03-09 15:31:08 UTC]: succeed


"clang++-3.6"  -Wl,-R -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-R -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-R -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-rpath-link -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-rpath-link -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -Wl,-rpath-link -Wl,"/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi" -o "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/notify_all_at_thread_exit_p" -Wl,--start-group "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/winrt_init.o" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_thread.so.1.58.0" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/chrono/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_chrono.so.1.58.0" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/system/build/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/libboost_system.so.1.58.0"  -Wl,-Bstatic  -Wl,-Bdynamic -lrt -Wl,--end-group -fsanitize=thread -lc++ -lc++abi -pthread 

RmTemps /home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/notify_all_at_thread_exit_p

    rm -f "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/sync/conditions/notify_all_at_thread_exit_pass.o" "/home/ben/development/boost/test/build/develop/results/boost/bin.v2/libs/thread/test/notify_all_at_thread_exit_p.test/clang-linux-3.6~tsan~c14_libc++/debug/debug-symbols-off/threading-multi/winrt_init.o"

            

Run [2015-03-09 15:31:08 UTC]: fail


==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Write of size 8 at 0x7fd7f9795c48 by thread T1:
    #0 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x00000002567a)

  Previous write of size 8 at 0x7fd7f9795c48 by main thread:
    #0 <null> <null> (0x000000000001)

  Location is stack of thread T1.

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::(anonymous namespace)::thread_proxy(void*)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Read of size 8 at 0x7d4c0000de58 by thread T1:
    #0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x0000000318e5)
    #1 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7d4c0000de58 by main thread (mutexes: write M24):
    #0 boost::shared_ptr<boost::detail::thread_data_base>::swap(boost::shared_ptr<boost::detail::thread_data_base>&) <null> (libboost_thread.so.1.58.0+0x000000031796)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::operator=(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x00000003142d)
    #2 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x000000025579)
    #3 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #4 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #5 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Location is heap block of size 424 at 0x7d4c0000de40 allocated by main thread:
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::thread_data<void (*)()>* boost::detail::heap_new<boost::detail::thread_data<void (*)()>, void (*)()>(void (*&&)()) <null> (notify_all_at_thread_exit_p+0x0000004c6acb)
    #2 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a87)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Mutex M24 (0x0000014d9438) created at:
    #0 pthread_mutex_init /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1082:3 (notify_all_at_thread_exit_p+0x00000045f790)
    #1 boost::mutex::mutex() <null> (notify_all_at_thread_exit_p+0x0000004c27d7)
    #2 __cxx_global_var_init10 <null> (notify_all_at_thread_exit_p+0x0000004439cc)
    #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp <null> (notify_all_at_thread_exit_p+0x000000443a43)
    #4 __libc_csu_init <null> (notify_all_at_thread_exit_p+0x0000004d538c)

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Write of size 8 at 0x7fd7f9795c38 by thread T1:
    #0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x0000000318f9)
    #1 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7fd7f9795c38 by main thread:
    #0 <null> <null> (0x000000000001)

  Location is stack of thread T1.

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Read of size 8 at 0x7d4c0000de60 by thread T1:
    #0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) <null> (notify_all_at_thread_exit_p+0x0000004c7696)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x000000031929)
    #2 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7d4c0000de60 by main thread (mutexes: write M24):
    #0 boost::detail::shared_count::swap(boost::detail::shared_count&) <null> (notify_all_at_thread_exit_p+0x0000004c71cb)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::swap(boost::shared_ptr<boost::detail::thread_data_base>&) <null> (libboost_thread.so.1.58.0+0x0000000317d6)
    #2 boost::shared_ptr<boost::detail::thread_data_base>::operator=(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x00000003142d)
    #3 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x000000025579)
    #4 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #5 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #6 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Location is heap block of size 424 at 0x7d4c0000de40 allocated by main thread:
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::thread_data<void (*)()>* boost::detail::heap_new<boost::detail::thread_data<void (*)()>, void (*)()>(void (*&&)()) <null> (notify_all_at_thread_exit_p+0x0000004c6acb)
    #2 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a87)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Mutex M24 (0x0000014d9438) created at:
    #0 pthread_mutex_init /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1082:3 (notify_all_at_thread_exit_p+0x00000045f790)
    #1 boost::mutex::mutex() <null> (notify_all_at_thread_exit_p+0x0000004c27d7)
    #2 __cxx_global_var_init10 <null> (notify_all_at_thread_exit_p+0x0000004439cc)
    #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp <null> (notify_all_at_thread_exit_p+0x000000443a43)
    #4 __libc_csu_init <null> (notify_all_at_thread_exit_p+0x0000004d538c)

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Write of size 8 at 0x7fd7f9795c40 by thread T1:
    #0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) <null> (notify_all_at_thread_exit_p+0x0000004c76aa)
    #1 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x000000031929)
    #2 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7fd7f9795c40 by main thread:
    #0 <null> <null> (0x000000000001)

  Location is stack of thread T1.

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::shared_count::shared_count(boost::detail::shared_count const&)
==================
==================
WARNING: ThreadSanitizer: data race (pid=14082)
  Atomic write of size 4 at 0x7d080000ef88 by thread T1:
    #0 __tsan_atomic32_fetch_add /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interface_atomic.cc:613:3 (notify_all_at_thread_exit_p+0x0000004a5256)
    #1 boost::detail::atomic_increment(int _Atomic*) <null> (notify_all_at_thread_exit_p+0x0000004c77cc)
    #2 boost::detail::sp_counted_base::add_ref_copy() <null> (notify_all_at_thread_exit_p+0x0000004c7749)
    #3 boost::detail::shared_count::shared_count(boost::detail::shared_count const&) <null> (notify_all_at_thread_exit_p+0x0000004c76e6)
    #4 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr(boost::shared_ptr<boost::detail::thread_data_base> const&) <null> (libboost_thread.so.1.58.0+0x000000031929)
    #5 boost::(anonymous namespace)::thread_proxy(void*) <null> (libboost_thread.so.1.58.0+0x0000000256a3)

  Previous write of size 8 at 0x7d080000ef88 by main thread (mutexes: write M24):
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::shared_count::shared_count<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6f67)
    #2 void boost::detail::sp_pointer_construct<boost::detail::thread_data_base, boost::detail::thread_data<void (*)()> >(boost::shared_ptr<boost::detail::thread_data_base>*, boost::detail::thread_data<void (*)()>*, boost::detail::shared_count&) <null> (notify_all_at_thread_exit_p+0x0000004c6dd0)
    #3 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6c7b)
    #4 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a93)
    #5 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #6 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Location is heap block of size 24 at 0x7d080000ef80 allocated by main thread:
    #0 operator new(unsigned long) /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:571:3 (notify_all_at_thread_exit_p+0x00000045aebd)
    #1 boost::detail::shared_count::shared_count<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6f67)
    #2 void boost::detail::sp_pointer_construct<boost::detail::thread_data_base, boost::detail::thread_data<void (*)()> >(boost::shared_ptr<boost::detail::thread_data_base>*, boost::detail::thread_data<void (*)()>*, boost::detail::shared_count&) <null> (notify_all_at_thread_exit_p+0x0000004c6dd0)
    #3 boost::shared_ptr<boost::detail::thread_data_base>::shared_ptr<boost::detail::thread_data<void (*)()> >(boost::detail::thread_data<void (*)()>*) <null> (notify_all_at_thread_exit_p+0x0000004c6c7b)
    #4 boost::thread::make_thread_info(void (*)()) <null> (notify_all_at_thread_exit_p+0x0000004c3a93)
    #5 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f82)
    #6 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

  Mutex M24 (0x0000014d9438) created at:
    #0 pthread_mutex_init /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:1082:3 (notify_all_at_thread_exit_p+0x00000045f790)
    #1 boost::mutex::mutex() <null> (notify_all_at_thread_exit_p+0x0000004c27d7)
    #2 __cxx_global_var_init10 <null> (notify_all_at_thread_exit_p+0x0000004439cc)
    #3 _GLOBAL__sub_I_notify_all_at_thread_exit_pass.cpp <null> (notify_all_at_thread_exit_p+0x000000443a43)
    #4 __libc_csu_init <null> (notify_all_at_thread_exit_p+0x0000004d538c)

  Thread T1 (tid=14087, running) created by main thread at:
    #0 pthread_create /home/development/llvm/3.6.0/final/llvm.src/projects/compiler-rt/lib/tsan/rtl/tsan_interceptors.cc:896:3 (notify_all_at_thread_exit_p+0x00000045e361)
    #1 boost::thread::start_thread_noexcept() <null> (libboost_thread.so.1.58.0+0x0000000255b0)
    #2 boost::thread::start_thread() <null> (notify_all_at_thread_exit_p+0x0000004c3ba3)
    #3 boost::thread::thread<void (&)()>(void (&)()) <null> (notify_all_at_thread_exit_p+0x0000004c2f8b)
    #4 main <null> (notify_all_at_thread_exit_p+0x0000004c0903)

SUMMARY: ThreadSanitizer: data race ??:0 boost::detail::atomic_increment(int _Atomic*)
==================
No errors detected.
ThreadSanitizer: reported 6 warnings

EXIT STATUS: 66
            

I compiled Boost 1.59.0 with Solaris Studio 12.4 in C++11 mode and I

get the following error messages:

"libs/thread/src/pthread/thread.cpp", line 144: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"libs/thread/src/pthread/thread.cpp", line 150: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"libs/context/src/posix/stack_traits.cpp", line 58: Error: Overloading ambiguity between "boost::call_once<void(&)(unsigned long*), unsigned long*>(boost::once_flag&, void(&)(unsigned long*), unsigned long*&&)" and "boost::call_once<void(*)(unsigned long*), unsigned long*>(boost::once_flag&, void(*)(unsigned long*), unsigned long*)".
"libs/context/src/posix/stack_traits.cpp", line 66: Error: Overloading ambiguity between "boost::call_once<void(&)(rlimit*), rlimit*>(boost::once_flag&, void(&)(rlimit*), rlimit*&&)" and "boost::call_once<void(*)(rlimit*), rlimit*>(boost::once_flag&, void(*)(rlimit*), rlimit*)".
"libs/coroutine/src/posix/stack_traits.cpp", line 56: Error: Overloading ambiguity between "boost::call_once<void(&)(unsigned long*), unsigned long*>(boost::once_flag&, void(&)(unsigned long*), unsigned long*&&)" and "boost::call_once<void(*)(unsigned long*), unsigned long*>(boost::once_flag&, void(*)(unsigned long*), unsigned long*)".
"libs/coroutine/src/posix/stack_traits.cpp", line 64: Error: Overloading ambiguity between "boost::call_once<void(&)(rlimit*), rlimit*>(boost::once_flag&, void(&)(rlimit*), rlimit*&&)" and "boost::call_once<void(*)(rlimit*), rlimit*>(boost::once_flag&, void(*)(rlimit*), rlimit*)".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/spirit/home/classic/phoenix/closures.hpp", line 427: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/spirit/home/classic/phoenix/closures.hpp", line 427: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".
"./boost/thread/once.hpp", line 38: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(*)()&>(boost::once_flag&, void(*)()&)".
"./boost/spirit/home/classic/core/non_terminal/impl/object_with_id.ipp", line 145: Error: Overloading ambiguity between "boost::call_once<void(*)()>(boost::once_flag&, void(*)())" and "boost::call_once<void(&)()>(boost::once_flag&, void(&)())".

I'm not 100% sure whether these are compiler issues or Boost compiler configuration issues thus I decided to raise this ticket.

I'm cross-compiling boost on Linux, having 32-bit mingw64 as a target.

I'm still seeing strict aliasing complaints on boost 1.63.0 thread/win32/shared_mutex.hpp.

As gcc 6 has even stricter aliasing rules, I'm afraid that these may be harmful, so I came up with the attached patch - which is ugly, but works.

The posix implementation of process real cpu clock uses the times() function. The resolution is better if we use

::clock_gettime( CLOCK_PROCESS_CPUTIME_ID, &ts );

on platforms for which the CLOCK_PROCESS_CPUTIME_ID is supported.

Based on Associate Mutexes with Data to Prevent Races, By Herb Sutter, May 13, 2010 - ​http://www.drdobbs.com/windows/associate-mutexes-with-data-to-prevent-r/224701827?pgno=3

"Make our mutex testable if it isn't already.

Many mutex services (including boost::mutex) don't provide a way to ask, "Do I already hold a lock on this mutex?"

Sometimes it is needed to know if a method like is_held to be available.

This wrapper associates an arbitrary lockable type with a thread id that stores the ID of the thread that currently holds the lockable. The thread id initially holds an invalid value that means no threads own the mutex.

When we acquire a lock, we set the thread id; and when we release a lock, we reset it back to its default no id state."

Once we will be able to disable thread interruption it would be great if we can provide interruptible threads on top of non-interruptible threads so that the user don't pay for what they don't use, but has yet a mechanism that allows work with interruptible and non-interruptible threads on the same executable.

See #7594 Allow to disallow thread interruptions

It would be great if boost::thread could be extended with a "hierarchical" mutex to facilitate lock hierarchies. Lock hierarchies is a construct that associates mutexes with software layer numbers, and enforces the application to only lock "downwards" in the software hierarchy [1]. This effectively translates potential deadlocks into deterministic run-time failures that be detected during testing.

An example draft implementation is attached. The attachment also includes a BOOST_THREAD_LOCAL work-around for missing "thread_local" support that should probably be moved to more neutral ground.

[1] ​http://www.drdobbs.com/parallel/use-lock-hierarchies-to-avoid-deadlock/204801163

See #8513 for the basic thread_pool interface

Base on ​http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_invoke algorithm.

The main difference is that the algorithm could take an Executor as parameter.

Base on ​http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_reduce algorithm.

The main difference is that the algorithm could take an Executor as parameter.

Base on ​http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3429.pdf and TBB Intel library add a parallel_for_each algorithm.

The main difference is that the algorithm could take an Executor as parameter.

As for ​http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3533.html#streaming_iterators add queue iterators.

I would like to be able to do

    typedef boost::synchronized_value< boost::container::flat_map<int, int> > ValueIndex;
    
    ValueIndex index;
    index[0] = 1;

and would expect that last line to be equivalent to

    auto locked_index = index.synchronize();
    (*locked_index)[0] = 1;

I'm not totally sure it's possible to do but it would help.

Follows the Fundamental TS wording for ::then() function.

Following N4123, add unwrap shared_future constructor

See also ​https://github.com/cplusplus/concurrency_ts/issues/58

shared_future(future<shared_future<R>>&& rhs) noexcept;

Effects:
    Constructs a shared_future object from the shared state referred to by rhs. The shared_future becomes ready when one of the following occurs:

        Both the outer future and the inner shared_future are ready. The shared_future inherits the value or the exception from the inner shared_future.
        The outer future is ready but the inner shared_future is invalid. The shared_future gets an exception of type std::future_error, with an error code of std::future_errc::broken_promise.

Postconditions:

        valid() returns the same value as rhs.valid() prior to the constructor invocation.
        valid() == true.
        rhs.valid() == false.

This function should help to implement a generic wait_for_any on models of Future.

When using Chrono I/O V2, currently there's no easy way to specify that only the numeric value of a duration without the unit should be output to a stream (equivalent of duration unit pattern "%v"). It would be useful to add a new enumerator, say 'no_unit', to duration_style enumeration, and a corresponding stream manipulator (e.g. 'no_unit_format').

lock_guard works with BasicLockable.

In order the variadic version to avoid deadlock, it can work only with Lockable, as the use of lock forces it.

Currently we have async function that constructs futures associated to an Executor.

The then() member function should use this executor to launch the continuation. See #11716.

But futures can also have other sources, as e.g. a promise or a packaged_task. This paper proposes the addition of Executor aware constructors for promise<T> and packaged_task<R(Args)> so that the continuation on the associated future make use of this executor.

We propose to:

• Add promise<T>::promise<T>(Executor&) Executor aware constructor.

• Add packaged_task<R(Args...)>::packaged_task(Executor&) Executor aware constructor.

http://www.boost.org/doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.io.ios_state_hpp.sag.set_time_fmt

table 6.3 on the page linked above describes format tags to be used with IO. Several are listed as unsupported. There is no explanation of what 'unsupported' means. Does it mean a format string with one of those tags will cause an exception? Will the format tag be ignored? Will the entire format string fail to work? Will interation over the string stop before or after the 'unsupported' tag? More explanation would be helpful here.

boost doc states that its steady_clock is system-wide, in doc/libs/1_59_0/doc/html/chrono/reference.html#chrono.reference.cpp0x.system_clocks_hpp.steady_clock

steady_clock class provides access to the system-wide steady clock.
The current time can be obtained by calling steady_clock::now().
There is no fixed relationship between values returned by
steady_clock::now() and wall-clock time. 

As far as I know, the C++11 standard does not make this requirement.

It would be good to highlight this discrepancy in the doc, especially since the doc "Included on the C++11 Recommendation" section let's you think that boost's chrono and std's chrono are interchangeable.

boost::condition_variable::timed_wait never returns if compiled with -DBOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC.

this_thread::sleep and thread::timed_join exhibit the same problem, but both these functions are documented as deprecated. However condition_variable::timed_wait is not documented as deprecated.

This can be worked around by using condition_variable::wait_for.

The following simple test program demonstrates the problem in that it hangs forever. Removing the #define makes it return after one second.

#define BOOST_THREAD_HAS_CONDATTR_SET_CLOCK_MONOTONIC

#include <boost/thread.hpp>
#include <iostream>

int main( int argc, char* argv[] )
{
    boost::condition_variable cv;
    boost::mutex m;
    boost::mutex::scoped_lock lock( m );

    cv.timed_wait( lock, boost::posix_time::seconds( 1 ) );
    std::cout << "wait_for has returned" << std::endl;

    return 0;
}

The current (as of boost 1.59) implementation of boost::shared_mutex for 'pthread' is pretty suboptimal as it's using a heavyweight mutex to guard the internal mutex state. This is more evident when shared locks are used to guard state whose access concurrency is high, due to contention on the mutex state lock (in these cases, the shared mutex is effectively exclusive). In comparison, the 'win32' implementation uses lightweight spinlocks underneath.

There are a couple options to fix this for 'pthread', e.g. using a spinlock or leveraging pthreads_rwlock. I'm happy to provide with an initial patch for this.

In build/tools/v2/tools/gcc.jam we are setting the LD_LIBRARY_PATH for compilation to:

/usr/bin:/usr/lib:/usr/lib32:/usr/lib64

Couple of points:

• /usr/bin (?) :D
• /usr/lib on FreeBSD does not contain major number libs so most if not all binaries will not pick up anything from here
• /usr/lib32 on FreeBSD DOES CONTAIN major number libs so if you are building on 32-bit this will work, HOWEVER if you are building 64-bit then this will cause failures
• /usr/lib64 does not exist on FreeBSD (I believe this is a Linux thing)

Based on the comments within gcc.jam I FEEL as do some other people (see thread reference) that if bjam is *really* going to rely on rtld then it should do so by NOT setting anything to LD_LIBRARY_PATH which many have pointed out is only to be used when the standard search path is not enough. Setting this PATH is very dangerous and for 99% of the build cases, rtld does the right thing.

Thread:

​http://www.nabble.com/Boost-1.36.0-FreeBSD-patches-for-review-td20143328.html

If it is decided to set LD_LIBRARY_PATH then we need to make this OS specific and unset it for FreeBSD (or minimally add back /lib which Steven pointed out in the above thread is probably not the right solution given LD_LIBRARY_PATH's semantics).

Hi,

calling "bootstrap.bat" results in successful compilation of boost_1_40_0\tools\jam\src\bin.ntx86_64\bjam.exe but this is not where the bootstrap.bat expects it to be, as it only supports x86 as it seems.

BTW: tools\jam\src\build.bat somehow finds my VS2010beta and uses that for compilation (although I'd like it to use my production VS9) and it seems I have no control of telling "bootstrap.bat" to use a custom toolset (this is supported by build.bat)

cheers Chris