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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Blocks|                            |56456
             Status|NEW                         |RESOLVED

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
Yes, it's a duplicate of pr94655 (and pr96259 reported just this morning).

The warning in this case is based on the following IL:

  _2 = &MEM[(struct sched_group_t *)sched_global.0_1 + 36B].lock;
  ...
 _4 = (sizetype) i_19;
  _5 = _4 * 40;
  _18 = _5 + 4;
  grp_name_10 = _2 + _18;
  __builtin_strncpy (grp_name_10, name_11(D), 31);
  MEM[(char *)grp_name_10 + 31B] = 0;

specifically grp_name_10 pointing to the lock member plus an offset it
determines is out of the bounds of the member for all elements of the enclosing
array.

The apparently out of bounds destination is substituted for the in bounds one
in the source by the PRE pass.  Just prior to it, the IL is:

  _4 = (sizetype) i_19;
  _5 = _4 * 40;
  _18 = _5 + 4;
  _17 = &MEM[(struct sched_group_t *)sched_global.0_1 + 36B];
  grp_name_10 = _17 + _18;
  __builtin_strncpy (grp_name_10, name_11(D), 31);
  MEM[(char *)grp_name_10 + 31B] = 0;

which doesn't provide a justification for the warning.  All middle end warnings
that attempt to detect invalid/out of bounds accesses (e.g., -Warray-bounds and
-Wstringo-overflow and others) rely on the subject (ether object or subobject)
in expressions like ARRAY_REF, COMPONENT_REF, and MEM_REF corresponding to the
source.  Transformations that break that assumption lead to false positives. 
To avoid compromising the utility of the warnings, either the transformations
need to change (e.g., to use MEM_REF (base, offset) rather than COMPONENT_REF
(MEM_REF ...)) or the IL needs to somehow/somewhere preserve the original
destination of the access.  (I plan to look into the former.)  Otherwise, the
only way to avoid issuing the warning would be to give up analyzing anything
with a MEM_REF in it.  Since MEM_REFs are pervasive in the IL (all but the most
trivial pointer accesses are transformed into one) this would reduce the
effectiveness of the warnings to just the trivial subset of code.

*** This bug has been marked as a duplicate of bug 94655 ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456
[Bug 56456] [meta-bug] bogus/missing -Warray-bounds

Reply via email to