On Wed, 15 Mar 2023, Jakub Jelinek wrote: > On Wed, Mar 15, 2023 at 10:49:19AM +0000, Richard Biener via Gcc-patches > wrote: > > The following switches the -Wuse-after-free diagnostics from emitted > > during the late access warning passes to the early access warning > > passes to make sure we run before passes performing code motion run > > which are the source of a lot of false positives on use-after-free > > not involving memory operations. > > > > The patch also fixes issues in c-c++-common/Wuse-after-free-6.c and > > g++.dg/warn/Wuse-after-free3.C. > > > > Bootstrapped and tested on x86_64-unknown-linux-gnu (without 1/2 > > sofar, but its testcase XFAILed). > > > > OK? > > > > Thanks, > > Richard. > > > > PR tree-optimization/109123 > > * gimple-ssa-warn-access.cc (pass_waccess::warn_invalid_pointer): > > Do not emit -Wuse-after-free late. > > (pass_waccess::check_call): Always check call pointer uses. > > > > * gcc.dg/Wuse-after-free-pr109123.c: New testcase. > > * c-c++-common/Wuse-after-free-6.c: Un-XFAIL case. > > * g++.dg/warn/Wuse-after-free3.C: Remove expected duplicate > > diagnostic. > > I guess this is this is related to the never ending debate of what to > do with the middle end late warnings, whether we should kill them > altogether, move into analyzer framework and/or run early but perform > IPA analysis for them.
Yes. And for -Wuse-after-free also whether value-uses are considered or not, but changing that has a much bigger testsuite fallout. > Doing the diagnostics in the early waccess pass is certainly fine > no matter what, it will emit there more accurate diagnostics. > A big question is whether to avoid diagnosing it late as well (other option > is just make sure we don't diagnose same statements twice, once in early > waccess and once in late waccess, which can be solved with warning > suppressions (unless it is already properly suppressed)), especially for > GCC 13. > I see we have two copies of early waccess (so, we need to get the > suppression right even if the warning is just moved to early waccess), > one is very shortly after building ssa, so before early inlining, > then there is another early one for -O+ non-Og shortly after IPA, > and the late one is immediately before expansion. Yep, I think the suppression should already work. > So, the question is if the ccp after IPA is sufficient to uncover > the most of the use after free issues we want to diagnose, if yes, > then perhaps your patch is ok but we need to decide what to do about > -Og, whether we shouldn't add > NEXT_PASS (pass_warn_access, /*early=*/true); > into -Og pass queue after > NEXT_PASS (pass_object_sizes); > or so. That would be possible for sure. But then there's not much done between the late early and the late pass so the late pass could run in both modes (but I don't feel like massaging that too much at this point). There's also -O0 where the late pass catches all always-inlined cases. > I think even the pre-IPA optimizations can do some harm for use after free > false positives, but hopefully not as much as the post IPA optimizations. We do some very limited jump-threading but I don't think there's much code-motion going on. Richard.
