[Bug c/100442] New: Spurious -Wstringop-overread error with odd boundaries

[Bug c/100442] New: Spurious -Wstringop-overread error with odd boundaries

[andres at anarazel dot de]

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

            Bug ID: 100442
           Summary: Spurious -Wstringop-overread error with odd boundaries
           Product: gcc
           Version: 11.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: andres at anarazel dot de
  Target Milestone: ---

Hi,

When compiling one of postgres' source files with -O3 I see the following:

gcc-11 -O3 -Wall -o /dev/null -c tsvector_op.i

In function 'tsCompareString',
    inlined from 'tsCompareString' at
/home/andres/src/postgresql/src/backend/utils/adt/tsvector_op.c:1147:1,
    inlined from 'tsvector_bsearch' at
/home/andres/src/postgresql/src/backend/utils/adt/tsvector_op.c:410:9:
/home/andres/src/postgresql/src/backend/utils/adt/tsvector_op.c:1164:23:
warning: 'memcmp' specified bound [18446744073709551612, 18446744073709551615]
exceeds maximum object size 9223372036854775807 [-Wstringop-overread]
 1164 |                 cmp = memcmp(a, b, Min(lena, lenb));
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                   

which does not seem plausible ;). As far as I can tell the values actually
passed to memcmp are reasonable.

I've attached both the preprocessed source file. I tried to reduce it using
creduce - but it hung and reported a bug (which I did, an hour ago).

andres@awork3:~/src/postgresql$ gcc-11 --version
gcc-11 (Debian 11.1.0-1) 11.1.0

This also happens with gcc-10 (except reported as -Wstringop-overflow=), but
not 9.


Regards,

Andres

[Bug tree-optimization/100442] Spurious -Wstringop-overread error with odd boundaries

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-05-06
             Status|UNCONFIRMED                 |WAITING

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I don't see the preprocessed source being attached.  I also tried to reproduce
it myself by recreating what the sources in postgres does but I could not.

[Bug tree-optimization/100442] Spurious -Wstringop-overread error with odd boundaries

[andres at anarazel dot de]

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

--- Comment #2 from Andres Freund <andres at anarazel dot de> ---
Created attachment 50763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50763&action=edit
preprocessed reproducer

Huh, sorry for that. I thought I had attached it. When I tried again now it
failed due to the size limit - maybe I somehow managed to submit the bug
despite that, but the size error caused the attachment to not be there
silently? Or I just forgot to press a button or such...

[Bug tree-optimization/100442] Spurious -Wstringop-overread error with odd boundaries

[msebor at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED

--- Comment #3 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning is working correctly: it sees (and prints) the range below.

;;   basic block 7, loop depth 1, count 2036975 (estimated locally), maybe hot
;;   Invalid sum of incoming counts 4073950 (estimated locally), should be
2036975 (estimated locally)
;;    prev block 6, next block 8, flags: (NEW, REACHABLE, VISITED)
;;    pred:       5 [50.0% (guessed)]  count:4073950 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  # RANGE [18446744073709551612, 18446744073709551615]   <<< excessive range
  _78 = (long unsigned intD.10) lexeme_len_24(D);
  # RANGE [0, 1048575] NONZERO 1048575
  _79 = (sizetype) _75;
  # PT = nonlocal 
  _80 = _7 + _79;
  # VUSE <.MEM_20(D)>
  # USE = nonlocal escaped 
  cmp_81 = memcmpD.890 (lexeme_23(D), _80, _78);         <<< -Wstringop-overead
  if (cmp_81 == 0)
    goto <bb 9>; [50.00%]
  else
    goto <bb 8>; [50.00%]

Ending up with an excessive range isn't uncommon in code that freely converts
between signed and unsigned integers (e.g., by passing an int to a size_t
argument) and involves conditionals like those in tsCompareString().  GCC must
assume the signed integers may be negative and convert to very large positive
values.  Changing tsCompareString() to take size_t arguments instead of int
avoids the warning:

  int32 tsCompareString(char *a, size_t lena, char *b, size_t lenb, _Bool
prefix);

Alternatively, asserting that the signed arguments aren't negative also
prevents the warning and in addition appears to result in better code
(tsvector_bsearch is inlined as well):

   ...
 else
 {
   if (lena < 0 || lenb < 0)
     __builtin_unreachable ();
  cmp = memcmp(a, b, ((lena) < (lenb) ? (lena) : (lenb)));

I don't think there is anything for GCC to do here.

[Bug tree-optimization/100442] Spurious -Wstringop-overread error with odd boundaries

[andres at anarazel dot de]

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

--- Comment #4 from Andres Freund <andres at anarazel dot de> ---
> Ending up with an excessive range isn't uncommon in code that freely converts between signed and unsigned integers (e.g., by passing an int to a size_t argument) and involves conditionals like those in tsCompareString().  GCC must assume the signed integers may be negative and convert to very large positive values.  Changing tsCompareString() to take size_t arguments instead of int avoids the warning:

That true - and I agree that that code isn't great.

But the warning message is quite confusing: A bound of "[18446744073709551612,
18446744073709551615]" doesn't sound right from the perspective a compiler
user, rather than compiler author. Clearly the lower bound isn't actually
18446744073709551612.