Skip to content
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

Fix compile with clang-3.5 #2462

Merged
merged 2 commits into from
May 27, 2016
Merged

Fix compile with clang-3.5 #2462

merged 2 commits into from
May 27, 2016

Conversation

springmeyer
Copy link
Contributor

Addresses #2459

{
segment_speeds_counters.emplace_back();
segment_speeds_counters[i].store(0);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this better than the for (auto &each : loop before?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clang35's stdlib does not support the vector constructor that takes a size when the template argument is a moveable only type. This is a bug in its stdlib. To work around this we default construct the vector, then loop n times adding a new counter and initializing it explicitly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@daniel-j-h is it really a bug in the standard library or clang-3.5 itself? I'm asking because the standard library was the same on the system this replicates on and g++ was not impacted, only clang.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have the error here, but I thought the constructor was calling the atomic' deleted copy assignment operator. The stdlib implementation of the vector does this. Could also be that clang35 just picks a wrong assignment operator?

@freenerd
Copy link
Member

freenerd commented May 25, 2016

did you run clang-format over this?

@springmeyer
Copy link
Contributor Author

@freenerd - no, will run clang-format next. But first it looks like this is not compiling on compilers that are not clang-3.5:

In file included from /usr/include/c++/4.8/vector:62:0,
                 from /usr/include/boost/filesystem/path_traits.hpp:26,
                 from /usr/include/boost/filesystem/path.hpp:25,
                 from /home/travis/build/Project-OSRM/osrm-backend/include/contractor/contractor_config.hpp:31,
                 from /home/travis/build/Project-OSRM/osrm-backend/include/contractor/contractor.hpp:31,
                 from /home/travis/build/Project-OSRM/osrm-backend/src/contractor/contractor.cpp:1:
/usr/include/c++/4.8/bits/stl_construct.h: In instantiation of ‘void std::_Construct(_T1*, _Args&& ...) [with _T1 = std::atomic<long unsigned int>; _Args = {std::atomic<long unsigned int>}]’:
/usr/include/c++/4.8/bits/stl_uninitialized.h:75:53:   required from ‘static _ForwardIterator std::__uninitialized_copy<_TrivialValueTypes>::__uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = std::move_iterator<std::atomic<long unsigned int>*>; _ForwardIterator = std::atomic<long unsigned int>*; bool _TrivialValueTypes = false]’
/usr/include/c++/4.8/bits/stl_uninitialized.h:117:41:   required from ‘_ForwardIterator std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with _InputIterator = std::move_iterator<std::atomic<long unsigned int>*>; _ForwardIterator = std::atomic<long unsigned int>*]’
/usr/include/c++/4.8/bits/stl_uninitialized.h:258:63:   required from ‘_ForwardIterator std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator, std::allocator<_Tp>&) [with _InputIterator = std::move_iterator<std::atomic<long unsigned int>*>; _ForwardIterator = std::atomic<long unsigned int>*; _Tp = std::atomic<long unsigned int>]’
/usr/include/c++/4.8/bits/stl_uninitialized.h:281:67:   required from ‘_ForwardIterator std::__uninitialized_move_if_noexcept_a(_InputIterator, _InputIterator, _ForwardIterator, _Allocator&) [with _InputIterator = std::atomic<long unsigned int>*; _ForwardIterator = std::atomic<long unsigned int>*; _Allocator = std::allocator<std::atomic<long unsigned int> >]’
/usr/include/c++/4.8/bits/vector.tcc:415:43:   required from ‘void std::vector<_Tp, _Alloc>::_M_emplace_back_aux(_Args&& ...) [with _Args = {}; _Tp = std::atomic<long unsigned int>; _Alloc = std::allocator<std::atomic<long unsigned int> >]’
/usr/include/c++/4.8/bits/vector.tcc:101:54:   required from ‘void std::vector<_Tp, _Alloc>::emplace_back(_Args&& ...) [with _Args = {}; _Tp = std::atomic<long unsigned int>; _Alloc = std::allocator<std::atomic<long unsigned int> >]’
/home/travis/build/Project-OSRM/osrm-backend/src/contractor/contractor.cpp:501:50:   required from here
/usr/include/c++/4.8/bits/stl_construct.h:75:7: error: use of deleted function ‘std::atomic<long unsigned int>::atomic(const std::atomic<long unsigned int>&)’
     { ::new(static_cast<void*>(__p)) _T1(std::forward<_Args>(__args)...); }
       ^
In file included from /home/travis/build/Project-OSRM/osrm-backend/include/util/dynamic_graph.hpp:13:0,
                 from /home/travis/build/Project-OSRM/osrm-backend/include/contractor/graph_contractor.hpp:6,
                 from /home/travis/build/Project-OSRM/osrm-backend/src/contractor/contractor.cpp:3:
/usr/include/c++/4.8/atomic:658:7: error: declared here
       atomic(const atomic&) = delete;
       ^

@TheMarex TheMarex force-pushed the fix-clang-3.5-compile branch from b1bcb25 to 4ae8abe Compare May 27, 2016 20:35
@TheMarex TheMarex merged commit 4ae8abe into master May 27, 2016
@TheMarex TheMarex deleted the fix-clang-3.5-compile branch May 27, 2016 20:36
@springmeyer
Copy link
Contributor Author

@TheMarex sorry, this was not passing yet. Per #2459 (comment) I wonder if this code can be re-written to avoid this brittle use of atomics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants