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

            Bug ID: 119367
           Summary: [15 Regression][gcn] libgomp.fortran/target1.f90 with
                    '-O2 -g': '.2byte .LM6-.LM5' – error: ... out of range
                    – since r15-8047-gadb14c7625178b
           Product: gcc
           Version: 15.0
            Status: UNCONFIRMED
          Keywords: openmp, wrong-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
                CC: ams at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---
            Target: gcn

This seems to be rather new as 2025-03-09 build does not have it but a
2025-03-17 has. And it seems to be generic (gfx900, gfx908, gfx90a, gfx1103)
and shows up llvm-mc of main and LLVM 19.

The error requires debugging turned on (-g) and -O2 or higher;
the testsuite uses -O3 -g


$ gfortran -fopenmp */*/libgomp.fortran/target1.f90  -O2 -g
-foffload=amdgcn-amdhsa

/tmp/ccZlSFQB.mkoffload.2.s:75841:9: error: value evaluated as 113052 is out of
range.
        .2byte  .LM6-.LM5
                ^
/tmp/ccZlSFQB.mkoffload.2.s:76003:9: error: value evaluated as 106240 is out of
range.
        .2byte  .LM34-.LM33
                ^
/tmp/ccZlSFQB.mkoffload.2.s:76013:9: error: value evaluated as 77232 is out of
range.
        .2byte  .LM36-.LM35
                ^
* * *

For a amdgcn-amdhsa-gfortran, in our automatic testing, the same issue shows up
for

  UNRESOLVED: gfortran.dg/associate_18.f08   -O3 -g  compilation failed to
produce 
(Easily to miss because of the UNRESOLVED instead of FAIL.)

However, trying it manually, it does not fail for me.

* * *

Bisecting points at:

commit adb14c7625178b501389c2d7d7c2feec37da7a19
Author: Richard Biener
Date:   Fri Mar 7 12:57:42 2025 +0100

    tree-optimization/119155 - wrong aligned access for vectorized packed
access

    When doing strided SLP vectorization we use the wrong alignment for
    the possibly piecewise access of the vector elements for loads and
    stores.  While we are carefully using element aligned loads and
    stores that isn't enough for the case the original scalar accesses
    are packed.  The following instead honors larger alignment when
    present but correctly falls back to the original scalar alignment
    used.

            PR tree-optimization/119155
            * tree-vect-stmts.cc (vectorizable_store): Do not always
            use vector element alignment for VMAT_STRIDED_SLP but
            a more correct alignment towards both ends.
            (vectorizable_load): Likewise.

            * gcc.dg/vect/pr119155.c: New testcase.

Reply via email to