https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122473
--- Comment #5 from James Abbatiello <abbeyj+gcc at gmail dot com> ---
I think what I want here is for this not to warn. The code is old and not
exactly pretty but it has been working well for years with no warnings and, as
far as I can tell, no out-of-bounds accesses. When I added `-march=x86-64-v3`,
it started to warn, which was unexpected. This made me worry: was this code
actually accessing out of bounds? Or maybe the compiler is generating
unconditional 16-byte writes here (i.e. generating wrong code) and then warning
me about that? I think that neither of those are applicable. I would have
been better off without this warning having been issued, which is why I filed
this bug.
> Also with the call case, well that needs full static anlysis power which this
> is out side of the scope of this warning; that is NOT out side of the scope
> of -fanalyzer though.
If the compiler could find a location where a too-long descriptor was being
passed into `print` then a warning about that would be fine. I don't expect
this to happen since it seems difficult and I'm fine living without such a
warning. As long as there is at least one possible use case where there will
be no out of bounds access (which I think my complete program demonstrates),
then I don't think a warning is appropriate.
I don't think that warning on any access that might possibly be out of bounds
is practical or desirable. Otherwise things like `void a(const char *s) { char
d[9]; strcpy(d, s); ... }` and `void b(int n) { char d[9]; d[n] = 0; ... }`
would have to warn. That seems like it would be far too noisy. AFAICT, the
rule has always been that you're on your own in situations like this. The
compiler will not really try to help you with any warning, and it is your
responsibility to be sure that the value that you're passing to the function is
suitable.
I'm not sure what the best way is to get this to no longer warn. Maybe the
compiler could notice that the destination is of size 9 and decide that this is
too small to benefit from vectorization and not vectorize the loop. This seems
like it could be a good idea overall since you probably don't want to spend the
time and space needed for vectorizing when it won't be useful?
Or maybe after doing the vectorization it could see that the part of the code
that looks like `while (bytes_left >= 16) { write_16_bytes(); bytes_left -= 16;
}` would invoke UB if it was ever run. It could eliminate that code entirely,
so there would be nothing left to warn about.
Or it could decide not to issue -Wstringop-overflow warnings for just that
loop. The rest of the code (including the code to handle the tail of 0 to 15
bytes) would still be able to issue this warning if appropriate. I'm assuming
that any warnings that came from there would be legitimate and desirable.
Or you could say that -Wstringop-overflow is too dependent on the details of
the optimizer and too inconsistent and remove it from -Wall.
