[Bug c/103111] New: bogus stringop overflow warning

[Bug c/103111] New: bogus stringop overflow warning

[k.melekhin at gmail dot com]

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

            Bug ID: 103111
           Summary: bogus stringop overflow warning
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: k.melekhin at gmail dot com
  Target Milestone: ---

Created attachment 51743
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51743&action=edit
test sample

Hello, please see the attachment.

Why is this warning being generated, it is clearly seen that there will only be
1 allocation and savepath->s_n is being set to 0. I know if I use unsigned
values warning goes away, but this warning still seems not right, because in
this case we are not even dealing with anything close to being considered
integer overflow.

I think this is a gcc bug, my appologies if this is known bug there seems to be
some similar open for c++ but not sure.

[Bug tree-optimization/103111] bogus stringop overflow warning

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So if I add:

        if (savepath->s_sz <= 0) __builtin_unreachable();
Before the check/setting of ->n. I get no warning.


If I unconditional set n to 0 rather than checking to see if it is greater than
0, I get no warning.

I think the warning might be correct due to GCC not being able to see all
pathes and knowing that n will never be negative.

[Bug tree-optimization/103111] bogus stringop overflow warning

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |msebor at gcc dot gnu.org

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning corresponds to the call below where the RANGE shows what it's based
on:

;;   basic block 10, loop depth 1, count 237404316 (estimated locally), maybe
hot
;;    prev block 9, next block 11, flags: (NEW, REACHABLE, VISITED)
;;    pred:       9 [80.5% (guessed)]  count:237404316 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  # RANGE [18446744071562067968, 18446744073709551615]
  _12 = (long unsigned intD.10) _5;
  # .MEM_39 = VDEF <.MEM_38>
  memcpyD.925 (_11, pretmp_90, _12);

Mixing signed and unsigned ints in computations involving sizes, especially in
LP64 where size_t is larger than int, tends to lead to excessive results that
might then end up either triggering warnings or lead to suboptimal code.  Using
unsigned integers (e.g., making sbuf's s_n and s_sz members unsigned) avoids
the warning and looks like also lets GCC emit better object code.