quality: improve warning flags and fix issues#321
Conversation
e1d392d to
849161f
Compare
f934ab0 to
56f0468
Compare
8a9068f to
07a92d1
Compare
…headers, ifdefs, dummy source Signed-off-by: Daniel Edwards <Daniel.Edwards@vector.com>
07a92d1 to
7ce3fee
Compare
…tem include directory Signed-off-by: Daniel Edwards <Daniel.Edwards@vector.com>
7ce3fee to
33d91cf
Compare
Signed-off-by: Daniel Edwards <Daniel.Edwards@vector.com>
33d91cf to
42466c6
Compare
|
Do you see any issues on your end regarding the changes in warning flags? You'll only have to take a look at this commit - the other changes are just fixing stuff found through additional warnings. |
|
Interestingly, these changes cause gcc12.3 to run into a GCC error:```sh In file included from .../gcc/12.3/include/c++/12.3.0/x86_64-pc-linux-gnu/bits/c++allocator.h:33, from .../gcc/12.3/include/c++/12.3.0/bits/allocator.h:46, from .../gcc/12.3/include/c++/12.3.0/string:41, from .../gcc/12.3/include/c++/12.3.0/stdexcept:39, from .../sil-kit/SilKit/include/silkit/participant/exception.hpp:7, from .../sil-kit/SilKit/include/silkit/SilKit.hpp:8, from .../sil-kit/Demos/communication/include/ApplicationBase.hpp:5, from .../sil-kit/Demos/communication/Rpc/RpcServerDemo.cpp:5: In member function 'void std::__new_allocator<_Tp>::deallocate(_Tp*, size_type) [with _Tp = unsigned char]', inlined from 'static void std::allocator_traits >::deallocate(allocator_type&, pointer, size_type) [with _Tp = unsigned char]' at .../gcc/12.3/include/c++/12.3.0/bits/alloc_traits.h:496:23, inlined from 'void std::_Vector_base<_Tp, _Alloc>::_M_deallocate(pointer, std::size_t) [with _Tp = unsigned char; _Alloc = std::allocator]' at .../gcc/12.3/include/c++/12.3.0/bits/stl_vector.h:387:19, inlined from 'std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = unsigned char; _Alloc = std::allocator]' at .../gcc/12.3/include/c++/12.3.0/bits/stl_vector.h:366:15, inlined from 'std::vector<_Tp, _Alloc>::~vector() [with _Tp = unsigned char; _Alloc = std::allocator]' at .../gcc/12.3/include/c++/12.3.0/bits/stl_vector.h:733:7, inlined from 'RpcServer::CreateControllers()::' at .../sil-kit/Demos/communication/Rpc/RpcServerDemo.cpp:86:9: .../gcc/12.3/include/c++/12.3.0/bits/new_allocator.h:158:33: error: 'void operator delete(void*, std::size_t)' called on pointer '' with nonzero offset [1, 4294967295] [-Werror=free-nonheap-object] 158 | _GLIBCXX_OPERATOR_DELETE(_GLIBCXX_SIZED_DEALLOC(__p, __n)); | ^ In member function '_Tp* std::__new_allocator<_Tp>::allocate(size_type, const void*) [with _Tp = unsigned char]', inlined from 'static _Tp* std::allocator_traits >::allocate(allocator_type&, size_type) [with _Tp = unsigned char]' at .../gcc/12.3/include/c++/12.3.0/bits/alloc_traits.h:464:28, inlined from 'std::_Vector_base<_Tp, _Alloc>::pointer std::_Vector_base<_Tp, _Alloc>::_M_allocate(std::size_t) [with _Tp = unsigned char; _Alloc = std::allocator]' at .../gcc/12.3/include/c++/12.3.0/bits/stl_vector.h:378:33, inlined from 'void std::_Vector_base<_Tp, _Alloc>::_M_create_storage(std::size_t) [with _Tp = unsigned char; _Alloc = std::allocator]' at .../gcc/12.3/include/c++/12.3.0/bits/stl_vector.h:395:44, inlined from 'std::_Vector_base<_Tp, _Alloc>::_Vector_base(std::size_t, const allocator_type&) [with _Tp = unsigned char; _Alloc = std::allocator]' at .../gcc/12.3/include/c++/12.3.0/bits/stl_vector.h:332:26, inlined from 'std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp = unsigned char; _Alloc = std::allocator]' at .../gcc/12.3/include/c++/12.3.0/bits/stl_vector.h:598:61, inlined from 'RpcServer::CreateControllers()::' at .../sil-kit/Demos/communication/Rpc/RpcServerDemo.cpp:72:57: .../gcc/12.3/include/c++/12.3.0/bits/new_allocator.h:137:55: note: returned from 'void* operator new(std::size_t)' 137 | return static_cast<_Tp*>(_GLIBCXX_OPERATOR_NEW(__n * sizeof(_Tp))); | ^ ```This is not a big deal for us at this point in time, as we are currently using gcc9.5 as our primary compiler for SilKit. However, anybody that uses gcc12.3 (and maybe even other minor versions of gcc12; I didn't test any others) would probably run into this same warning/error. On the other hand, this seems like it might actually be a bug in that version of gcc, as older and newer versions of gcc do not produce the warning, so it might not be worth 'fixing' in the SilKit code base. What are your thoughts @snps-fricke @VDanielEdwards ? We are also still seeing some |
Subject
Enables more warning flags for GCC and fixes resulting issues.
Developer checklist (address before review)