quality: improve warning flags and fix issues - #321
Conversation
e1d392d to
849161f
Compare
VDanielEdwards
changed the title
f934ab0 to
56f0468
Compare
VDanielEdwards
added
needs reviewer
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: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<std::allocator<_CharT> >::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<unsigned char>]' 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<unsigned char>]' 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<unsigned char>]' at .../gcc/12.3/include/c++/12.3.0/bits/stl_vector.h:733:7,
inlined from 'RpcServer::CreateControllers()::<lambda(SilKit::Services::Rpc::IRpcServer*, SilKit::Services::Rpc::RpcCallEvent)>' 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 '<unknown>' 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<std::allocator<_CharT> >::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<unsigned char>]' 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<unsigned char>]' 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<unsigned char>]' 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<unsigned char>]' at .../gcc/12.3/include/c++/12.3.0/bits/stl_vector.h:598:61,
inlined from 'RpcServer::CreateControllers()::<lambda(SilKit::Services::Rpc::IRpcServer*, SilKit::Services::Rpc::RpcCallEvent)>' 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 |
The dependency on the optimization level may indicate it is a similar issue as in this bugreport for GCC, although there it occured when no optimizations were applied. I agree that this isn't worth 'fixing'. I've looked through the code where the error originates, but I didn't notice anything obvious.
That is a good idea, added |
…headers, ifdefs, dummy source Signed-off-by: Daniel Edwards <Daniel.Edwards@vector.com>
…tem include directory Signed-off-by: Daniel Edwards <Daniel.Edwards@vector.com>
Signed-off-by: Daniel Edwards <Daniel.Edwards@vector.com>
e688617 to
6d460e6
Compare
3 participants
Subject
Enables more warning flags for GCC and fixes resulting issues.
Developer checklist (address before review)