Hi David, Sorry for not being active these past two weeks I've been overwhelmed at my university with creating a new club and other uni stuff.
I just went back to solving these 3 bugs we discussed last time. <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439> PR109439 <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109439> is the one about the double warnings emitted (both OOB and use of uninitialized value). Your second suggestion of terminating the diagnostic path on an OOB proved to interfere with PR109437. I might actually close PR109437 as solving PR109439 will probably solve it too. I'm going with your first suggestion of bubbling a boolean from check_region_bounds up to get_rvalue. I'm considering two approaches 1. preventing the check_for_poison call if there is an OOB Read. 2. or marking the OOB values as Unknown rather than Poisoned, but then we are semantically incorrect. Another unrelated question, I felt like the use of an uninitialized value terminating the path was a bit strong. No other warnings will be considered for the remaining of the function if there is such use, even for unrelated stuff. Like a double free on a completely different variable. Couldn't we tune that so we only ignore everything related to any variable tainted by this uninitialized value ? Sorry again for the past weeks, the club is finally running (somewhat). Benjamin. PS: I submitted a patch, bootstrapped and regtested, for the bug I was solving on gcc-request. I guess I'm not too clear on the process of submitting a patch, as I probably had to commit and push it afterwards, sadly there was no feedback on the previous RFC as well as on the patch submission - no blaming at all, people are busy and the flow of mails is massive. I believe I still don't have the right to commit it directly to the repo, and honestly even if I would using my fresh gcc account, I would prefer not to commit it myself for the first patch, I don't wanna mess with anything because of an oversight.
