Created attachment 57330 [details] reproduction GCC emits a bogus warning in the attached reproduction when compiled with sanitizers flags and O3. -O3 -std=c++17 -Wall -fsanitize=undefined -fsanitize=address See In file included from /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/atomic:41, from <source>:1: In member function 'std::__atomic_base<_IntTp>::__int_type std::__atomic_base<_IntTp>::load(std::memory_order) const [with _ITp = bool]', inlined from 'std::atomic<bool>::operator bool() const' at /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/atomic:87:26, inlined from 'void Foo::foo()' at <source>:22:32: /opt/compiler-explorer/gcc-13.2.0/include/c++/13.2.0/bits/atomic_base.h:505:31: warning: 'unsigned char __atomic_load_1(const volatile void*, int)' writing 1 byte into a region of size 0 overflows the destination [-Wstringop-overflow=] 505 | return __atomic_load_n(&_M_i, int(__m)); | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~ In member function 'void Foo::foo()': cc1plus: note: destination object is likely at address zero Compiler returned: 0 I had a look at the bugs linked to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443, but I couldnt find a similar scenario. Apologies if it is already known.
See https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Instrumentation-Options.html#index-fsanitize_003dundefined Note that sanitizers tend to increase the rate of false positive warnings, most notably those around -Wmaybe-uninitialized. We recommend against combining -Werror and [the use of] sanitizers.
Yeah, the 'cc1plus: note: destination object is likely at address zero' message hints at that we likely diagnose a threaded path where the pointer is zero. We were likely inclined to perform the threading by dynamic checks inserted by the sanitizer.