https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 24 Jul 2019, glisse at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227 > > --- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> --- > When we compare p>=a where a is an array (char a[3];), we can assume that p > points somewhere into the array and fold it to true (unless we decide that it > is too risky, and that for instance since we allow pointers one past the end, > we should also allow pointers one before the beginning). That's generally possible for p >= &x, independent of whether x is an array. > It is only in the rare > case where we happen to know that p cannot point into the array that we might > want to do something different (one possibility would be to fold the > comparison > to an undefined ssa_name), but that shouldn't prevent the 'true' optimization > for valid code paths. Path isolation might arrive too late, after we have > already folded to true. Using an undef SSA name might trigger odd uninit warnings though, but yes. Note I've yet have to see a testcase that shows the optimization is useful for real code (the p >= &x I can imagine though), that is, optimize the case where we _know_ p and q do not point to the same object and p and q are compared with a non-equality compare. I'd say we should not fold and path-isolate the case instead (and consider moving that earlier if it's too late). Since such compares invoke undefined behavior I hope they do not come from STL template instantiation for example.
