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