-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Failed to compile with -D_GLIBCXX_PARALLEL #489
Comments
I remember transforming that for loop into the accumulate function we currently use: assert(std::accumulate(first, last, std::pair<bool, int>(true, 0),
[&first](std::pair<bool, int> res, decltype(*first) val)
{
res.first &= (val == *(std::next(std::addressof(*first), res.second++)));
return res;
}).first); Unless I made a mistake and this does not do the same as the |
I could reproduce the problem with
running macOS Sierra 10.12.3. |
Perhaps you could simply check that the distance between the pointers to first and last is the same as the distance between the corresponding iterators? |
This bug track seems to explain it: TLDR: the specification has an extra requirement for std::accumulate() because each thread needs and init value. GCC assumes an init value per thread by de-referencing the first iterator. |
Right, it's this:
|
Since in a threaded loop the addresses get split up, it won't be easy to check that for thread_id > 0, the beginning address (assigned to this thread) is continuous wrt. to the previous chunk of addresses given to another thread. Therefore I think the only way to check for address continuity is to use the single threaded loop as I have quoted from that original SO post. |
Right, I think this is the solution then. |
The is_contiguous lambda is only used in an assertion, so it can be removed if NDEBUG is defined.
I can confirm that it compiles fine now with "-D_GLIBCXX_PARALLEL" on Homebrew GCC 6.1.0. Thanks a lot. |
Hello,
json.hpp builds OK normally (even with -fopenmp) but would not build with gcc flags "-D_GLIBCXX_PARALLEL". I suspect this is because of different type rules in STL when parallel flag is on:
This is on MacOSX 10.12.3 with Homebrew gcc 6.1.0.
The assertion at line 6461 was causing the problem. I found that if we follow http://stackoverflow.com/a/35008842/266378 more faithfully, e.g. by defining
and replacing the assertion by calling
assert(is_contiguous(first, last));
this error seems to go away. However I'm not an expert in STL so was hoping someone could verify this.
The text was updated successfully, but these errors were encountered: