[Bug c/109269] New: [sve] should check the upper bound for predicate sve

[Bug c/109269] New: [sve] should check the upper bound for predicate sve

[zhongyunde at huawei dot com]

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

            Bug ID: 109269
           Summary: [sve] should check the upper bound for predicate sve
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhongyunde at huawei dot com
  Target Milestone: ---

* test case:https://gcc.godbolt.org/z/jde11xv53
```
void mset (int *a, long long num) {
   for (long long i=0; i< num; i++)
     a[i] = 2;
}
```
* Base on above case, gcc don't check the upper bound,
  so when the input num is very large, such as 0xfffffffffffffffe, and the
vscale is 4 (512-bit scalable vector), so the "add     x2, x2, x3" in the loop
body may be overflow, when the check "whilelo p0.s, x2, x1" will always be true
?

* see detail for gcc's assemble
```
mset:
        cmp     x1, 0
        ble     .L1
        mov     x2, 0
        cntw    x3
        whilelo p0.s, xzr, x1
        mov     z0.s, #2
.L3:
        st1w    z0.s, p0, [x0, x2, lsl 2]
        add     x2, x2, x3    --  may be overflow ?
        whilelo p0.s, x2, x1
        b.any   .L3
.L1:
        ret
```

[Bug c/109269] [sve] should check the upper bound for predicate sve

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
That would be undefined code as the largest array is 63bits.

[Bug c/109269] [sve] should check the upper bound for predicate sve

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Pointers cannot wrap that is once a pointer is a valid pointer, adding anything
to it cannot get you a null pointer.
In this case a large argument to num would cause an for the pointers so gcc
knows num has to be less than LONG_LONG_MAX/sizeof(int).

[Bug c/109269] [sve] should check the upper bound for predicate sve

[zhongyunde at huawei dot com]

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

--- Comment #3 from vfdff <zhongyunde at huawei dot com> ---
* test: https://gcc.godbolt.org/z/5s4Wbs466
```
void mset (int *a, int num) {
   for (int i=0; i< num; i++)
     a[i] = 2;
}
```

* the issue is still exist with int type as we use 32-bits register? . see
detail on gcc's assemble:

```
mset:
        cmp     w1, 0
        ble     .L1
        mov     x2, 0
        cntw    x3
        whilelo p0.s, wzr, w1
        mov     z0.s, #2
.L3:
        st1w    z0.s, p0, [x0, x2, lsl 2]
        add     x2, x2, x3   --  overflow a 32-bit value ?
        whilelo p0.s, w2, w1   
        b.any   .L3
.L1:
        ret
```

[Bug c/109269] [sve] should check the upper bound for predicate sve

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
But that would be undefined code still.
If num was INT_MAX-3 in the int case, it might be valid.
I have to think further on that.

But that is a corner case where you would have an array which is huge.

[Bug tree-optimization/109269] [sve] should check the upper bound for predicate sve

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING
                 CC|                            |rsandifo at gcc dot gnu.org
   Last reconfirmed|                            |2023-04-13

--- Comment #5 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> ---
I don't think there's a problem with the example in comment 3.  The loop is
(deliberately) using 64-bit arithmetic, so no overflow will occur even for
num==INT_MAX.

[Bug tree-optimization/109269] [sve] should check the upper bound for predicate sve

[rsandifo at gcc dot gnu.org]

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

Richard Sandiford <rsandifo at gcc dot gnu.org> changed:

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

--- Comment #6 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
Based on the discussion, I don't think there's a bug here.