dispenso: [Bug]: Build fails with `-Werror` on 32-bit platform
Contact Details
No response
What happened?
Build fails on 32-bit platform when warnings are treated as errors.
In file included from /opt/local/include/gcc13/c++/atomic:41,
from /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_dispenso/dispenso/work/dispenso-1.2.0/dispenso/../dispenso/platform.h:14,
from /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_dispenso/dispenso/work/dispenso-1.2.0/dispenso/../dispenso/detail/small_buffer_allocator_impl.h:13,
from /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_dispenso/dispenso/work/dispenso-1.2.0/dispenso/small_buffer_allocator.cpp:8:
In member function 'std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = long unsigned int]',
inlined from 'bool moodycamel::ConcurrentQueue<T, Traits>::ExplicitProducer::enqueue_bulk(It, moodycamel::ConcurrentQueue<T, Traits>::size_t) [with moodycamel::ConcurrentQueue<T, Traits>::AllocationMode allocMode = moodycamel::ConcurrentQueue<char*, moodycamel::ConcurrentQueueDefaultTraits>::CanAlloc; It = char**; T = char*; Traits = moodycamel::ConcurrentQueueDefaultTraits]' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_dispenso/dispenso/work/dispenso-1.2.0/dispenso/third-party/moodycamel/concurrentqueue.h:2060:49,
inlined from 'bool moodycamel::ConcurrentQueue<T, Traits>::inner_enqueue_bulk(const producer_token_t&, It, size_t) [with AllocationMode canAlloc = moodycamel::ConcurrentQueue<char*, moodycamel::ConcurrentQueueDefaultTraits>::CanAlloc; It = char**; T = char*; Traits = moodycamel::ConcurrentQueueDefaultTraits]' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_dispenso/dispenso/work/dispenso-1.2.0/dispenso/third-party/moodycamel/concurrentqueue.h:1382:124,
inlined from 'bool moodycamel::ConcurrentQueue<T, Traits>::enqueue_bulk(const producer_token_t&, It, size_t) [with It = char**; T = char*; Traits = moodycamel::ConcurrentQueueDefaultTraits]' at /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_dispenso/dispenso/work/dispenso-1.2.0/dispenso/third-party/moodycamel/concurrentqueue.h:1052:38:
/opt/local/include/gcc13/c++/bits/atomic_base.h:505:31: error: 'unsigned int __atomic_load_4(const volatile void*, int)' writing 4 bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
505 | return __atomic_load_n(&_M_i, int(__m));
| ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~
In function 'bool moodycamel::ConcurrentQueue<T, Traits>::enqueue_bulk(const producer_token_t&, It, size_t) [with It = char**; T = char*; Traits = moodycamel::ConcurrentQueueDefaultTraits]':
cc1plus: note: destination object is likely at address zero
cc1plus: all warnings being treated as errors
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_dispenso/dispenso/work/dispenso-1.2.0/dispenso/timed_task.cpp: In member function 'void dispenso::TimedTaskScheduler::timeQueueRunLoop()':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_dispenso/dispenso/work/dispenso-1.2.0/dispenso/timed_task.cpp:86:28: error: redundant move in initialization [-Werror=redundant-move]
86 | auto next = std::move(tasks_.top());
| ~~~~~~~~~^~~~~~~~~~~~~~
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_dispenso/dispenso/work/dispenso-1.2.0/dispenso/timed_task.cpp:86:28: note: remove 'std::move' call
cc1plus: all warnings being treated as errors
Perhaps these are nothing critical, but if they are easily fixable, it may be worth addressing this.
Version
latest (Edge)
Code of Conduct
- I agree to follow this project’s Code of Conduct
About this issue
- Original URL
- State: open
- Created 6 months ago
- Comments: 34 (34 by maintainers)
Sorry for a delay, will do it tonight.
Great info, thanks @barracuda156. I’ll try turning that off for GCC. I hate doing it, as I usually want all diagnostics, but it really doesn’t make sense in this case. I’ll try to get something landed this week, and after that, I’ll cut a new release that incorporates all of these small recent fixes.
Building from 4ebef42e38c85f3d2ef213cb6edc7146eee521e6 – that still fails:
Same with
-Wstringop-overflow=2. It does build with-Wno-stringop-overflow, however (and no patches).Bummer. Okay, I will have to look deeper, and/or possibly just try to disable this warning. Thanks for checking.
@graphicsMan Will do tonight, thank you for a reminder.
@graphicsMan Thank you! I am away from the testing hardware atm, gonna be back by middle of next week. Will update on this as soon as I can.
Thanks @barracuda156 for reporting the issues, for the commit, and for testing my patch.
I think there was one more issue you reported, related to compiler warning-as-error in moodycamel lib. I didn’t repro that with my arm32 cross-compile. It may be that we want to treat moodycamel as a “system” library, so that we don’t get warnings from that code. I’m not sure how to do that in CMake. I found this, but haven’t had a chance to take a deeper look, and it might be a week or two until I can get back to this: https://stackoverflow.com/questions/52135983/cmake-target-link-libraries-include-as-system-to-suppress-compiler-warnings
If you wanted to try something and verify it for your platform, I’d happily accept another commit, otherwise, I can try to get back to this in a bit.
Okay, interesting . I just managed to successfully build and link libdispenso.so with x-compile arm32 on Linux. Now I’m able to repro the missing libatomic stuff. I’ve looked at various projects (TBB, taskflow, folly), and none of these seem to support arm32 or ppc32. I’m unsure the right way to add libatomic only as required, though I have been searching around and found this approach, which may or may not be sufficient: https://stackoverflow.com/questions/69281559/cmake-library-order-in-cmake-required-libraries-to-test-a-minimal-program-while
Do you have experience fixing this (with CMake in particular) for your projects?
Wonderful. We currently do the vast majority of our work on 64-bit, and even with 32-bit, internal to the company we are not using CMake. Any way you can help is welcome. I’d love PRs or patches, but I’ll try to get to these either way (biggest concern is setting up the correct cross-compiling toolchains, etc… which I don’t have that much experience with).
Thanks very much for the report.
The timed_task move issue is fixed in mainline.
The other two issues may depend on platform and toolchain. Are these only PPC, ARM, MIPS 32-bit issues? Unfortunately I don’t currently have any machines set up to replicate.
Would you be willing to try updating the moodycamel concurrentqueue library locally to see if that fixes the first problem? It may be that this is something that just popped up with newer versions of GCC (I’ve personally only tested up to GCC 11), and they may already have fixed it in moodycamel. If that is the case, I’ll be happy to update the copy.
The second problem likely needs a CMakeLists.txt update to pull in libatomic. The trouble is that I don’t have a clear sense of when that is required. Maybe if CMake can detect a 32-bit build we could always link.