On Mon, 31 Jan 2022, 22:03 Segher Boessenkool, <segher@xxxxxxxxxxxxxxxxxxx>
wrote:
> On Mon, Jan 31, 2022 at 02:49:43PM -0700, Martin Sebor wrote:
> > Some statements are also isolated from the source code even when they
> > don't appear there, or appear with different arguments. That's also
> > what happens in this case: GCC replaces the memcpy call and
> > the subsequent store with two: one pair is valid and another pair
> > of invalid statements. Here's the problem in the IL the warning
> > sees and points out:
> >
> > <bb 4> [count: 0]:
> > memcpy (4B, &somedata[0], 6); <<< -Warray-bounds
> > MEM[(struct hdr2 *)0B].h21 ={v} 0; <<< causes path isolation
> > __builtin_trap (); and trap to be added
>
> Yup. And GCC does not (yet) consider that memcpy to be UB itself, or
> the trap would be moved there, removing the warning. This may be the
> best we can get :-)
>
> (This of course requires the analysis to be always correct :-) )
>
> > More to your point, it's also an example where warnings issued for
> > code that's reachable only under some conditions make it seem like
> > they point out unconditional bugs.
>
> Yes, this is hard to understand often. It makes it easy to think GCC
> is wrong and the user code is correct (esp. for the user who wrote it).
>
Especially true when GCC is wrong and the user code is correct as written.
