[Bug tree-optimization/107699] [12/13/14 Regression] False positive -Warray-bounds, non-existent offset reported by GCC

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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...)?