Re: How to diagnose a false positive warning

On 5/12/2026 9:43 PM, Michael Welsh Duggan via Gcc-help wrote:
> g++ 16 ends up triggering a new false positive warning in some of my
> code that didn't trigger in g++ 15.  An example of this warning:
>
> In file included from /home/md5i/src/ipfix/master/tests/build.hpp:6,
>                   from /home/md5i/src/ipfix/master/tests/read.cpp:7:
> In function ‘void ipfix::convert::to_chunk_unsafe(auto:65&&, T) [with T = unsigned int; auto:65 = std::span<unsigned char>]’,
>      inlined from ‘build::message& build::message::set_domain(build::u32)’ at /home/md5i/src/ipfix/master/tests/build.hpp:202:29,
>      inlined from ‘virtual void ReadTest_EmptyMessages_Test::TestBody()’ at /home/md5i/src/ipfix/master/tests/read.cpp:262:19:
> /home/md5i/src/ipfix/master/src/../include/detail/conversions.hpp:244:14: error: writing 4 bytes into a region of size 0 [-Werror=stringop-overflow=]
>    244 |   std::memcpy(data(chunk), start, size(chunk));
>        |   ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> In member function ‘virtual void ReadTest_EmptyMessages_Test::TestBody()’:
> cc1plus: note: destination object is likely at address zero
>
> I'm fairly certain that this is a false positive, but the code is too
> complex to reproduce here.  I started to work on a minimal reproducer,
> but, again, the code is quite layered and complex.  I know I can ignore
> the warning using diagnostic pragmas, but I prefer not to do that unless
> completely necessary.  Can anyone recommend a way to debug why this
> warning is triggered?
To understand why it's getting triggered, you're likely going to have to 
get into the guts of GCC.  This code in particular is pretty hairy as 
it's a middle end diagnostic.  Meaning that it runs in the middle-end as 
it wants to have access to things like range information on objects, 
potentially the alias oracle and other components.  It's also going to 
be inherently sensitive to things like transformations made by the 
optimizers that can hide or expose these kinds of problems depending on 
the precise context.

The usual way to approach is to get a smaller testcase with the caveat 
that it's definitely possible to over-reduce a test resulting in a test 
that may trigger that warning, but remove whatever pieces of information 
are necessary to ultimately prove it's a false positive.

Also note there are many bugs of this nature in the bugzilla database.  
There may be duplicates in terms of the warning generated, but until you 
do the hard work of understanding precisely why the warning is generated 
for both your code and a potential duplicate it's impossible to know if 
they're caused by the same root issue.

Finally, the engineer that did most of the work on this class of 
warnings no longer works on GCC.  So we've lost the engineer that can 
debug these problems the fastest.

The net is my recommendation would be to get that minimal reproducer if 
you can and get it filed as a bug.  Then use the diagnostic pragmas to 
work around if that's an option for you.  Those don't always work for 
middle end warnings due to interactions with optimization passes and 
such.  But they're still your best bet.

jeff