https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103073
--- Comment #13 from hubicka at kam dot mff.cuni.cz --- > > diff --git a/gcc/ipa-modref-tree.h b/gcc/ipa-modref-tree.h > > index 9976e489697..1b51323175b 100644 > > --- a/gcc/ipa-modref-tree.h > > +++ b/gcc/ipa-modref-tree.h > > @@ -813,6 +818,20 @@ struct GTY((user)) modref_tree > > > > bool changed = false; > > > > + /* We may end up with max_size being less than size for accesses past > > the > > + end of array. Those are undefined and safe to ignore. */ > > + if (a.range_info_useful_p () > > + && ((known_size_p (a.size) && known_size_p (a.max_size) > > + && known_lt (a.max_size, a.size)) > > What about maybe_lt? Well, you should know the ICEing place and > whether it's sensitive to may or must ;) The range merging really went funny way because max_size == 0 and I hope in that case we will always have known_lt. But indeed I may need to proofread the merging logic for maybes (I even do not know how to produce testcases with non-trivial polyints here). Maybe_lt is IMO not safe since it may make us to ignore stores that are valid on runtime (given that the variable length vector type is small enough to fit in max_size). > > > + || (known_size_p (a.max_size) > > + && known_le (a.max_size, 0)))) > > The known_size_p (a.max_size) && known_le (a.max_size, 0) should never > be true (there's only the -1 special value denoting 'unknown'). OK, I will add a sanity check since it seemed from the code earlier that negative values may happen (which would be indeed sloppy if it was happening). > > Yeah, apart from the remark above. Thanks. I will update the patch. Honza > > -- > You are receiving this mail because: > You are the assignee for the bug. > You are on the CC list for the bug.
