[Bug middle-end/109449] [11/12/13 Regression] false positive stringop-overflow

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109449

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
      Known to fail|                            |11.3.0
           Priority|P3                          |P2
     Ever confirmed|0                           |1
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
            Summary|false positive              |[11/12/13 Regression] false
                   |stringop-overflow           |positive stringop-overflow
      Known to work|                            |10.4.0
   Last reconfirmed|                            |2023-04-12
   Target Milestone|---                         |11.4

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the code is correct.  What we see is for example

_11 = (int) ivtmp.16_45;
_12 = (sizetype) _11;
_13 = &drlg.D.2834.transDirMap[0][0] + _12;
*_13 = tpm_21;

and it seems to be confused about the computed object size from
pointer-query.cc
via handle_mem_ref of *_13 which eventually computes the size of
&drlg.D.2834.transDirMap[0][0] and then eventually does

static bool
handle_array_ref (tree aref, gimple *stmt, bool addr, int ostype,
                  access_ref *pref, ssa_name_limit_t &snlim,
                  pointer_query *qry)
{
...
  if (ostype && TREE_CODE (eltype) == ARRAY_TYPE)
    {
      /* Except for the permissive raw memory functions which use
         the size of the whole object determined above, use the size
         of the referenced array.  Because the overall offset is from
         the beginning of the complete array object add this overall
         offset to the size of array.  */
      offset_int sizrng[2] =
        {
         pref->offrng[0] + orng[0] + sz,
         pref->offrng[1] + orng[1] + sz
        };
      if (sizrng[1] < sizrng[0])
        std::swap (sizrng[0], sizrng[1]);
      if (sizrng[0] >= 0 && sizrng[0] <= pref->sizrng[0])
        pref->sizrng[0] = sizrng[0];
      if (sizrng[1] >= 0 && sizrng[1] <= pref->sizrng[1])
        pref->sizrng[1] = sizrng[1];

thus it thinks we offset transDirMap[0] and thus run out of that bound.

That's wishful thinking outside of any coding reality.  The following
fixes all of the bogus diagnostics.  But will likely regress some of the
testsuite, will check what.  There are likely duplicates of this bug.
I think it's definitely valid C and only in violation of some stricter
security-style coding rules and thus definitely shouldn't behave like this
by default.

diff --git a/gcc/pointer-query.cc b/gcc/pointer-query.cc
index 5b05e9bedf8..067e264fddb 100644
--- a/gcc/pointer-query.cc
+++ b/gcc/pointer-query.cc
@@ -1834,7 +1834,7 @@ handle_array_ref (tree aref, gimple *stmt, bool addr, int
ostype,
   orng[0] *= sz;
   orng[1] *= sz;

-  if (ostype && TREE_CODE (eltype) == ARRAY_TYPE)
+  if (!addr && ostype && TREE_CODE (eltype) == ARRAY_TYPE)
     {
       /* Except for the permissive raw memory functions which use
         the size of the whole object determined above, use the size