https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87489
--- Comment #16 from Martin Sebor <msebor at gcc dot gnu.org> --- The test case in https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565564.html shows that running the -Wnonnull pass later, after FRE, allows the warning to detect the bug in the following test case: class b { public: long c(); }; class B { public: B() : f() {} b *f; }; long d, e; class g : B { public: void h() { long a = f->c(); <<< -Wnonnull d = e = a; } }; class j { j(); g i; }; j::j() { i.h(); } My response (https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565590.html) is copied below: > Thanks. Yes, the warning would be useful here since the f pointer > in the call to f->c() is null when i.h() is called from j's ctor. > The FRE3 pass clearly exposes this : > > void j::j (struct j * const this) > { > long int _9; > > <bb 2> [local count: 1073741824]: > MEM[(struct B *)this_3(D)] ={v} {CLOBBER}; > MEM[(struct B *)this_3(D)].f = 0B; > _9 = b::c (0B); > ... > > Because the warning runs early (after CCP2), the null pointer is > not detected. To see it the warning code would have to work quite > hard to figure out that the two assignments below refer to the same > location (it would essentially have to do what FRE does): > > MEM[(struct B *)this_3(D)].f = 0B; > _7 = MEM[(struct b * *)_1]; > _9 = b::c (_7); > > It's probably too late to make this change for GCC 11 as Jeff has > already decided that it should be deferred until GCC 12, and even > then there's a concern that doing so might cause false positives. > I think it's worth revisiting the idea in GCC 12 to see if > the concern is founded. Let me make a note of it in the bug.
