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?