[Bug tree-optimization/108377] New: Unexpected 'exceeds maximum object size' diagnostic, wrong-code?

[Bug tree-optimization/108377] New: Unexpected 'exceeds maximum object size' diagnostic, wrong-code?

[tschwinge at gcc dot gnu.org]

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

            Bug ID: 108377
           Summary: Unexpected 'exceeds maximum object size' diagnostic,
                    wrong-code?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54249
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54249&action=edit
1.c

Am I confused (it's late), or is GCC?  For '-O2' and higher:

    1.c: In function ‘f’:
    1.c:22:12: warning: argument 1 value ‘18446744073709551615’ exceeds maximum
object size 9223372036854775807 [-Walloc-size-larger-than=]
       22 |   needle = __builtin_malloc(n); /* { dg-bogus {exceeds maximum
object size} } */
          |            ^~~~~~~~~~~~~~~~~~~
    1.c:22:12: note: in a call to built-in allocation function
‘__builtin_malloc’

Manually reduced from some other test case.

Same issue for actual 'malloc', and 'size_t'.

This supposedly bogus 'needle' diagnostic disappears if I disable the
'haystack' allocation of 'n + 1'.

Actually, is this wrong-code?

    1.c.128t.sra:  _2 = __builtin_malloc (_1);
    1.c.128t.sra:  _5 = __builtin_malloc (n_14);

    1.c.129t.thread1:  _2 = __builtin_malloc (_1);
    1.c.129t.thread1:  _10 = __builtin_malloc (n_14);
    1.c.129t.thread1:  _5 = __builtin_malloc (n_14);

    1.c.130t.dom2:  _2 = __builtin_malloc (_1);
    1.c.130t.dom2:  _10 = __builtin_malloc (18446744073709551615);
    1.c.130t.dom2:  _5 = __builtin_malloc (n_14);

    [...]

    1.c.194t.fre5:  _2 = __builtin_malloc (_1);
    1.c.194t.fre5:  _10 = __builtin_malloc (18446744073709551615);
    1.c.194t.fre5:  _5 = __builtin_malloc (n_14);

    1.c.195t.thread2:  _2 = __builtin_malloc (_1);
    1.c.195t.thread2:  _10 = __builtin_malloc (18446744073709551615);
    1.c.195t.thread2:  _33 = __builtin_malloc (n_14);
    1.c.195t.thread2:  _5 = __builtin_malloc (n_14);

    1.c.196t.dom3:  _2 = __builtin_malloc (_1);
    1.c.196t.dom3:  _10 = __builtin_malloc (18446744073709551615);
    1.c.196t.dom3:  _33 = __builtin_malloc (i_51);
    1.c.196t.dom3:  _5 = __builtin_malloc (0);

    [...]

    1.c.254t.optimized:  _2 = __builtin_malloc (_1);
    1.c.254t.optimized:  _10 = __builtin_malloc (18446744073709551615);
    1.c.254t.optimized:  _33 = __builtin_malloc (i_51);
    1.c.254t.optimized:  _5 = __builtin_malloc (0);

[Bug tree-optimization/108377] Unexpected 'exceeds maximum object size' diagnostic, wrong-code?

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
That's x86_64-pc-linux-gnu at today's commit
de99049f6fe5341024d4d939ac50d063280f90db.

[Bug tree-optimization/108377] Unexpected 'exceeds maximum object size' diagnostic, wrong-code?

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
So we have:
  const __SIZE_TYPE__ n = calc_n(259);
#if 1
  haystack = __builtin_malloc(n + 1);
  if (!haystack)
    __builtin_abort();
  for (__SIZE_TYPE__ i = 0; i < n + 1; ++i)
    haystack[i] = '0';
#endif
  needle = __builtin_malloc(n); 

If calc_n(259) returns (__SIZE_TYPE__)-1 (aka 18446744073709551615). n+1 would
be 0 which will is fine for malloc. and then the for is skipped if n+1 == 0 and
a jump threading happens so you get two copies of the second malloc and then
you get a malloc which has 18446744073709551615.

So the warning is correct (and code produced) in some sense of correctness.
Maybe the best thing is add an assume after the call to calc_n that it will be
small or smaller than the n or so.

[Bug tree-optimization/108377] Unexpected 'exceeds maximum object size' diagnostic, wrong-code?

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Just adding:

  if (n+1 == 0)  __builtin_unreachable();
Right before the first malloc removes the warning as expected.

[Bug tree-optimization/108377] Unexpected 'exceeds maximum object size' diagnostic, wrong-code?

[tschwinge at gcc dot gnu.org]

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

--- Comment #4 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Thanks, Andrew, for looking into this.

(In reply to Andrew Pinski from comment #2)
> If calc_n(259) returns (__SIZE_TYPE__)-1 (aka 18446744073709551615) [...]
> the warning is correct ([...]) in some sense of correctness.

So, when GCC makes such "special" assumptions, should that really lead into a
generic diagnostic being emitted (as reported), where that diagnostic does not
spell out those assumptions?