> On Jan 6, 2025, at 09:21, Jeff Law <jeffreya...@gmail.com> wrote: > > > > On 1/6/25 7:11 AM, Qing Zhao wrote: >>> >>> Given it doesn't cause user visible UB, we could insert the trap *before* >>> the UB inducing statement. That would then make the statement unreachable >>> and it'd get removed avoiding the false positive diagnostic. >> Yes, that’s a good idea. >> However, in order to distinguish a user visible UB and a UB in the IL that >> is introduced purely by compiler, we might need some new marking in the IR? > I don't think we've ever really tackled that question; the closest I can > think of would be things like integer overflow which we try to avoid allowing > the compiler to introduce. If we take the integer overflow as the model, > then that would say we should be tackling this during loop unrolling.
UB that is introduced by compiler transformation is one important cause of false positive warnings. There are two approaches to tackle this problem from my understanding: 1. Avoid generating such UB from the beginning. i.e, for every compiler transformation that might introduce such UB, we should add check to avoid generating it. 2. Marking the IR portion that were generated by compiler transformations, then check whether the UB is compiler generated when issue static checker warnings. Are there other approaches? The above is very rough and initial idea at this moment. Qing > > jeff >
