- Boost-users - lists.preview.boost.org

Re: [Boost-users] [boost] [signals2][variant] inline warning with MSVC 2022
by Frank Mori Hess 22 Sep '22

22 Sep '22

On Thu, Sep 22, 2022 at 8:57 AM Peter Dimov <pdimov(a)gmail.com> wrote: > > That's complete nonsense. First, Microsoft invented __forceinline, so > making BOOST_FORCEINLINE be a no-op on the very compiler for which > the feature has been added would be ridiculous. Second, it does force > inlining, that's why it's called __forceinline. The whole point of the warning > is to warn about the rare cases where the compiler does not honor the > command; it exists because people want to know whether their "force > inline" orders are ignored. But no boost user wants to be warned about some internal implementation detail of a boost library. So every boost usage of BOOST_FORCEINLINE needs to add a #pragma warning(disable: 4714), awesome! Who is the maintainer of variant anyways? -- Frank

1 0

TSan error with boost::interprocess::message_queue on macOS ARM
by vl01＠jens-carl.de 22 Sep '22

22 Sep '22

Hello List, I'm using the boost::interprocess::message_queue in a project and to verify everything is working I created a test case. In that test case I'm sending and receiving data via threads. The test passes on Linux, Windows with no sanitizer and also with AddressSanitizer and ThreadSanitizer. I recently added Apple Silicon (M1) to the test matrix and now the test run with ThreadSanitizer enabled fails. Is boost::interprocess::message_queue thread-safe? Can the reported TSan error be an false-positive? If it that case, what test can I run to verify that? I looked at code of atomic_cas32() and it uses the legacy built-in __sync_val_compare_and_swap(). Can it be that that built-in isn't supported on ARM? Is there a newer built-in which should be used? The reported TSan error: -- snip ================== WARNING: ThreadSanitizer: data race (pid=4146) Atomic write of size 4 at 0x000104af4028 by thread T2: #0 __tsan_atomic32_compare_exchange_val <null>:81245684 (libclang_rt.tsan_osx_dynamic.dylib:arm64e+0x57854) #1 boost::interprocess::ipcdetail::atomic_cas32(unsigned int volatile*, unsigned int, unsigned int) atomic.hpp:581 (tsan_boost:arm64+0x100005b30) Previous read of size 4 at 0x000104af4028 by thread T1: #0 boost::interprocess::ipcdetail::spin_mutex::try_lock() mutex.hpp:100 (tsan_boost:arm64+0x100006eb0) #1 void boost::interprocess::ipcdetail::try_based_lock<boost::interprocess::ipcdetail::spin_mutex>(boost::interprocess::ipcdetail::spin_mutex&) common_algorithms.hpp:62 (tsan_boost:arm64+0x100006e28) SUMMARY: ThreadSanitizer: data race atomic.hpp:581 in boost::interprocess::ipcdetail::atomic_cas32(unsigned int volatile*, unsigned int, unsigned int) -- snap Here is a code example which demonstrates the test case -- snip #include <boost/interprocess/ipc/message_queue.hpp> #include <iostream> #include <vector> #include <thread> #include <memory> struct MessageQueueImpl { MessageQueueImpl() { boost::interprocess::permissions file_permissions; file_permissions.set_permissions(0660); queue = std::make_unique<boost::interprocess::message_queue>(boost::interprocess::create_only, "tsanqueue", 10, 15, file_permissions); } std::unique_ptr<boost::interprocess::message_queue> queue; }; class MessageQueue { public: MessageQueue() : m_impl(std::make_unique<MessageQueueImpl>()) {} void send(const std::vector<uint8_t>& buffer) { m_impl->queue->send(buffer.data(), buffer.size(), 0); } void receive(std::vector<uint8_t>& buffer) { boost::interprocess::message_queue::size_type received_size = 0; buffer.resize(m_impl->queue->get_max_msg_size()); uint32_t prio; m_impl->queue->receive(buffer.data(), buffer.size(), received_size, prio); buffer.resize(received_size); } private: std::unique_ptr<MessageQueueImpl> m_impl; }; int main() { auto uut = std::make_unique<MessageQueue>(); std::thread sender([&uut]{ for(uint8_t i = 0; i < 3; ++i) { const std::vector<uint8_t> send_buffer = {i}; uut->send(send_buffer); } }); std::thread receiver([&uut]{ for(uint8_t i = 0; i < 3; ++i) { std::vector<uint8_t> receive_buffer; uint32_t prio; uut->receive(receive_buffer); std::cout << "buffer received:\n"; for (const auto i : receive_buffer) { std::cout << i << '\n'; } } }); if(sender.joinable()) { sender.join(); } if(receiver.joinable()) { receiver.join(); } return 0; } -- snap Cheers, Jens

3 3

Re: [Boost-users] [boost] [signals2][variant] inline warning with MSVC 2022
by Frank Mori Hess 22 Sep '22

22 Sep '22

On Wed, Sep 21, 2022 at 12:32 PM Peter Dimov <pdimov(a)gmail.com> wrote: > > That's not very user friendly; maybe the user _wants_ the warning in his code, > and the above would disable it even if no Boost header that uses > BOOST_FORCEINLINE (and generates a warning) has been included. > Okay, then maybe BOOST_FORCEINLINE shouldn't be defined as __force_inline on compilers where it doesn't actually force inlining. If the compiler is just going to treat it as a suggestion, I don't see the point of boost headers using it and then suppressing the warning. -- Frank

1 0

[signals2][variant] inline warning with MSVC 2022
by Gavin Lambert 21 Sep '22

21 Sep '22

This may not be a new issue, as I'm trying to update a project from Boost 1.68 to 1.80 (big jump!), but in trying to compile I'm being hit with this lengthy warning (and this particular project is building with warnings as errors, so this is problematic): warning C4714: function 'class boost::variant<class boost::shared_ptr<void>,class boost::signals2::detail::foreign_void_shared_ptr> __cdecl boost::detail::variant::visitation_impl<struct boost::mpl::int_<0>,struct boost::detail::variant::visitation_impl_step<struct boost::mpl::l_iter<struct boost::mpl::l_item<struct boost::mpl::long_<3>,class boost::weak_ptr<class boost::signals2::detail::trackable_pointee>,struct boost::mpl::l_item<struct boost::mpl::long_<2>,class boost::weak_ptr<void>,struct boost::mpl::l_item<struct boost::mpl::long_<1>,class boost::signals2::detail::foreign_void_weak_ptr,struct boost::mpl::l_end> > > >,struct boost::mpl::l_iter<struct boost::mpl::l_end> >,class boost::detail::variant::invoke_visitor<class boost::signals2::detail::lock_weak_ptr_visitor const ,0>,void const *,struct boost::variant<class boost::weak_ptr<class boost::signals2::detail::trackable_pointee>,class boost::weak_ptr<void>,class boost::signals2::detail::foreign_void_weak_ptr>::has_fallback_type_>(int,int,class boost::detail::variant::invoke_visitor<class boost::signals2::detail::lock_weak_ptr_visitor const ,0> &,void const *,struct boost::mpl::bool_<0>,struct boost::variant<class boost::weak_ptr<class boost::signals2::detail::trackable_pointee>,class boost::weak_ptr<void>,class boost::signals2::detail::foreign_void_weak_ptr>::has_fallback_type_,struct boost::mpl::int_<0> *,struct boost::detail::variant::visitation_impl_step<struct boost::mpl::l_iter<struct boost::mpl::l_item<struct boost::mpl::long_<3>,class boost::weak_ptr<class boost::signals2::detail::trackable_pointee>,struct boost::mpl::l_item<struct boost::mpl::long_<2>,class boost::weak_ptr<void>,struct boost::mpl::l_item<struct boost::mpl::long_<1>,class boost::signals2::detail::foreign_void_weak_ptr,struct boost::mpl::l_end> > > >,struct boost::mpl::l_iter<struct boost::mpl::l_end> > *)' marked as __forceinline not inlined I'm not sure whether the Real Bug™ is in signals2 or in variant, but I don't think it's in any of my code since it doesn't name any of my types above that I can see. I tried the big stick of setting all of Boost to "external" (and set the external warning level to 0), but sadly this did not suppress the warning. Wrapping it in a #pragma suppression does hide the warning, which makes me sufficiently happy. But perhaps someone might be interested to poke at it?

2 2

version 1.78.0 compile failed on centos 7 with compiler clang
by David Frank 15 Sep '22

15 Sep '22

error message: boost/spirit/home/classic/phoenix/closures.hpp:274:30: error: default initialization of an object of const type 'const index<0>' without a user-provided default constructor Thanks.

1 0

version 1.78.0 compile failed on centos 7
by David Frank 15 Sep '22

15 Sep '22

error message: boost/spirit/home/classic/phoenix/closures.hpp:274:30: error: default initialization of an object of const type 'const index<0>' without a user-provided default constructor Thanks.

1 0

version 1.78.0 compile failed on centos 7
by David Frank 15 Sep '22

15 Sep '22

error message: boost/spirit/home/classic/phoenix/closures.hpp:274:30: error: default initialization of an object of const type 'const index<0>' without a user-provided default constructor On Saturday, September 3, 2022 at 08:48:54 PM PDT, David Frank <david_frank95(a)yahoo.com> wrote: I'm currently using version 60, it failed to compile with openssl 3.0.5. So I need to upgrade to a version that works. Thanks.

1 0

Redefined macro on Solaris, OmniOS, and SmartOS
by Camden Narzt 11 Sep '22

11 Sep '22

Building code (on Solaris, OmniOS, and SmartOS, using gcc) which includes boost, produces warnings such as the following: In file included from src/boost/config/platform/solaris.hpp:17:0, from src/boost/config.hpp:57, from src/boost/cstdint.hpp:36, from src/code_that_includes_boost.cpp:43: src/boost/config/posix_features.hpp:27:0: warning: "BOOST_HAS_STDINT_H" redefined [enabled by default] # define BOOST_HAS_STDINT_H ^ Not a big deal, but figured I’d report it in case it hadn’t been reported yet.

1 0

which version works with openssl 3.0.5?
by David Frank 04 Sep '22

04 Sep '22

I'm currently using version 60, it failed to compile with openssl 3.0.5. So I need to upgrade to a version that works. Thanks.

2 1

How to build Boost with static ICU via Msys2 / mingw-w64 / gcc on Windows?
by crillion＠tiscali.it 03 Sep '22

03 Sep '22

Hello, I'm trying to build boost 1.80 on windows 10 with the icu provided with msys2 (my goal in particular is that boost locale will build using my installed version of icu). My build platform is msys2 with mingw-w64 / gcc 12.2. By launching pacman -Q on the msys2-msys shell I have seen that I have icu 71.1-2 : (...) glib2 2.72.2-2 gmp 6.2.1-2 gnupg 2.2.36-1 grep 1~3.0-3 gzip 1.12-2 heimdal-libs 7.7.0-3 icu 71.1-2 inetutils 1.9.4-5 info 6.8-4 less 590-2 (...) on my system I have msys2 installed in the following folder C:programsmsys64 and in C:programsmsys64mingw64 there are the following folders : bin etc include lib libexec sbin share ssl var x86_64-w64-mingw32 in the lib folder I have found that there are lib files like libicuio.a, libicudt.a and libicutest.a . I extracted boost and then I've given the usual sequence of commands from the normal cmd shell of windows : for creating b2 : bootstrap.bat gcc for the actual build of boost, I've made the following attempts : b2 --toolset=gcc address-model=64 -sICU_PATH=C:programsmsys64mingw64 b2 --toolset=gcc address-model=64 include=C:programsmsys64mingw64include library-path=C:programsmsys64mingw64lib b2 --toolset=gcc address-model=64 -sICU_PATH=C:programsmsys64mingw64 include=C:programsmsys64mingw64include library-path=C:programsmsys64mingw64lib but none of these works : the build process always writes in its initial phase : (...) has_lzma_cputhreads builds : yes [2] cxx11_decltype : yes [2] cxx11_basic_alignas : yes [2] iconv (libc) : no [2] iconv (separate) : yes [2] icu : no [2] icu (lib64) : no [2] native atomic int32 supported : yes [2] has message compiler : no [2] native syslog supported : no [2] (...) what am I supposed to do to let b2 see the ICU lib files that I have in my msys2 distribution ? Thanks, Marco Voucher MISE per P.IVA e PMI: fino a 2500€ per la Banda Ultralarga. https://casa.tiscali.it/promo/?u=https://promozioni.tiscali.it/voucher_busi…..

1 0