Hi David,
I used the below code snippet to experiment with out-of-bounds (OOB) on
trunk. Three things occurred that I believe could see some improvement. See
https://godbolt.org/z/57n459cEs for the warnings.
int consecutive_oob_in_frame ()
{
int arr[] = {1,2,3,4,5,6,7};
int y1 = arr[9]; // only this one get warnings (3*2 actually), expect
only 1 OOB though
int y2 = arr[10]; // expect a warning too, despite fooling with asm
int y3 = arr[50]; // expect a warning for that one too (see asm)
return (y1+y2+y3);
}
int goo () {
int x = consecutive_oob_in_frame (); // causes another pair of warnings
return 2 * x;
}
int main () {
goo (); // causes another pair of warning
consecutive_oob_in_frame (); // silent
int x [] = {1,2};
x[5]; /* silent, probably because another set of OOB warnings
has already been issued with this frame being the source */
return 0;
}
First, as the subject line reads, I get a
-Wanalyzer-use-of-uninitialized-value for each -Wanalyzer-out-of-bounds. I
feel it might be too much, as fixing the OOB would fix the former.
So maybe only OOB could result in a warning here ?
Second, it seems that if a frame was a cause for a OOB (either by
containing the spurious code or by being a caller to such code), it will
only emit one set of warning, rather than at each unique compromising
statements.
Finally, I think the diagnostic path should only go at deep as the
declaration of the injurious index.
What do you think ? If they also make sense to you I will open a RFE and
try my hands at fixing them.
Also, have you considered extending the current call summaries model
(symbolic execution from what you told me), to implement a partial VASCO
model ? There would still be no need for distributive problems.
Maybe a start could be that functions without parameters working on
non-mutable global data should not generate EN more than once, rather than
at each call sites.
Best,
Benjamin.
