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

            Bug ID: 117709
           Summary: [15 regression] maskload else case generating wrong
                    code
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ams at gcc dot gnu.org
                CC: rdapp at gcc dot gnu.org
  Target Milestone: ---

The following testcase aborts on amdgcn since the maskload else patches were
added (https://patchwork.sourceware.org/project/gcc/list/?series=40395, plus
the patch for pr117657).

-----------8<-----------
int i, j;                                                       
int k[11][101];                                                 

__attribute__((noipa)) void                                     
doit (void) {                                                   
  int err = 0;                                                  
  for (j = -11; j >= -41; j -= 15)     {                        
    k[0][-j] = 1;                                               
  }                                                             
#pragma omp simd collapse(2) lastprivate (i, j) reduction(|:err)
  for (i = 4; i < 8; i += 12)                                   
    for (j = -8 * i - 9; j < i * -3 + 6; j += 15)               
      err |= (k[0][-j] != 1);                                   

  if (err)                                                      
    __builtin_abort ();                                         
}                                                               
int main () {                                                   
  doit ();                                                      
}                                                               
-----------8<-----------

The testcase is simplified from gcc.dg/vect/vect-simd-17.c.

If I revert most of the gcn patch, but keep the new operand with the
"maskload_else_operand" predicate, so that the backend generates the
zero-initializer, but the middle-end assumes the lanes are undefined, then the
testcase still fails.

I think this shows that the problem in in the additional code generated by the
middle end, not that the vectors are actually corrupt, but I've not identified
exactly how.

Reply via email to