https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Carlos Galvez from comment #11) > Consider this more realistic example: > > https://godbolt.org/z/jbbqbe8d9 > > The compiler has all the information available to ensure that > getCount().get() is smaller than 3, as enforced by the class invariant which > is visible to the compiler. Class invariants help us not having to check > things all the time. For example gsl::not_null allows us to not have to > check for nullptr on every use. This doesn't really change anything as the compiler doesn't see the CTOR invoked or that 'x' isn't changed before being returned. I think we want to somehow prevent the diagnostic on the library side. This particular case is /// This is a helper function for the sort routine. template<typename _RandomAccessIterator, typename _Compare> _GLIBCXX20_CONSTEXPR void __final_insertion_sort(_RandomAccessIterator __first, _RandomAccessIterator __last, _Compare __comp) { if (__last - __first > int(_S_threshold)) { std::__insertion_sort(__first, __first + int(_S_threshold), __comp); std::__unguarded_insertion_sort(__first + int(_S_threshold), __last, __comp); } else std::__insertion_sort(__first, __last, __comp); where we diagnose __first + int(_S_threshold) when that's visibly out-of-bounds but __last - __first isn't constant. I'm not exactly sure how (I'm also not sure why we do the above thing, handling the first elements separate from the rest...)?
