https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116461
--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #2)
> The easiest fix is todo:
> ```
> for (int i = 0; i < N; ++i)
> {
> a[i] = BASE1 + i * 5;
> b[i] = BASE2 - i * 4;
> /* b[i] cannot be 0 as that is undefined for `% b[i]`. */
> b[i] = b[i] ? b[i] : 1;
> __asm__ volatile ("");
> }
> ```
>
> On x86_64, I suspect we are getting a trap on the `% b[i]` rather than a
> comparison difference too. Which is why the fix should be on the
> initialization rather than the checking.
I made/tested a patch like:
diff --git a/gcc/testsuite/gcc.dg/vect/vect-mod-var.c
b/gcc/testsuite/gcc.dg/vect/vect-mod-var.c
index eeed318c62b..112048bd84c 100644
--- a/gcc/testsuite/gcc.dg/vect/vect-mod-var.c
+++ b/gcc/testsuite/gcc.dg/vect/vect-mod-var.c
@@ -22,7 +22,10 @@ main (void)
for (int i = 0; i < N; ++i)
{
a[i] = BASE1 + i * 5;
- b[i] = BASE2 - i * 4;
+ b[i] = BASE2 - i * 3;
+ /* There can be undefined remainder for zero b[i]. */
+ if (!b[i])
+ __builtin_abort ();
__asm__ volatile ("");
}
but your proposed fix is more straightforward, will you post it?