https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
--- Comment #15 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 21 Apr 2020, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 > > --- Comment #12 from Jeffrey A. Law <law at redhat dot com> --- > SO it's not terrible to get the key block cleaned up. but that's not > sufficient to resolve this issue. We all missed an important tidbit. > > > VRP is complaining about this: > > ps.D.2041.s = &MEM <byte> [(void *)&c + 7B]; > > > Note the object we reference in the &MEM expression, "c". "c" is a byte: > > typedef unsigned char byte; > byte c; > > > One could argue the problem is FRE. Prior to fre3 we had: > > ;; basic block 9, loop depth 0 > ;; pred: 7 > _34 = ps.D.2041.s; > _35 = _34 + 7; > ps.D.2041.s = _35; > > fre3 turns that into: > > ps.D.2041.s = &MEM <byte> [(void *)&c + 7B]; > > And we're going to lose. > > One could also argue that the warning has to be tolerant of these actions from > FRE. The question would be how to do that without totally compromising the > warning. FRE does an identity transform. That VRP does not warn about POINTER_PLUS_EXPR &c + 7B (I think it would?) may be another issue. That is FRE does _34 = ps.D.2041.s; -> _34 = &c; _35 = _34 + 7; -> _35 = &c + 7; // propagatable form &MEM[&c + 7] ps.D.2041.s = _35; -> ps.D.2041.s = &MEM[&c + 7]; aka nothing wrong.
