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. PR109439 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.