[Bug target/101484] New: [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[Bug target/101484] New: [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[doko at debian dot org]

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

            Bug ID: 101484
           Summary: [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa
                    (gcn offload)
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at debian dot org
  Target Milestone: ---

trunk 20210717 ftbfs the gcn offload compiler (using a just built 20210717
trunk build):

configuration complains about:

checking assembler for working .subsection -1...
/packages/gcc/snap/gcc-snapshot-20210717/bin-gcn/nm: error: conftest.o The fil
e was not recognized as a valid object file

/packages/gcc/snap/gcc-snapshot-20210717/bin-gcn/nm: error: conftest.o The file
was not recognized as a valid object file

no


The linker tools point to the ones provided by LLVM 9.

Later then:

libtool: compile: 
/packages/gcc/snap/gcc-snapshot-20210717/build-gcn/./gcc/gfortran
-B/packages/gcc/snap/gcc-snapshot-20210717
/build-gcn/./gcc/ -nostdinc
-B/packages/gcc/snap/gcc-snapshot-20210717/build-gcn/amdgcn-amdhsa/newlib/
-isystem /packages/gcc/s
nap/gcc-snapshot-20210717/build-gcn/amdgcn-amdhsa/newlib/targ-include -isystem
/packages/gcc/snap/gcc-snapshot-20210717/src-gcn
/newlib/libc/include -B/usr/lib/gcc-snapshot/amdgcn-amdhsa/bin/
-B/usr/lib/gcc-snapshot/amdgcn-amdhsa/lib/ -isystem /usr/lib/gc
c-snapshot/amdgcn-amdhsa/include -isystem
/usr/lib/gcc-snapshot/amdgcn-amdhsa/sys-include -L. -Wall -L../libgfortran -c
../../.
./src-gcn/libgomp/config/accel/openacc.f90 -o openacc.o
In file included from ../../../src-gcn/libgomp/barrier.c:28:
In function 'gcn_thrs',
    inlined from 'gomp_thread' at ../../../src-gcn/libgomp/libgomp.h:803:10,
    inlined from 'GOMP_barrier' at ../../../src-gcn/libgomp/barrier.c:34:29:
../../../src-gcn/libgomp/libgomp.h:792:10: error: array subscript 0 is outside
array bounds of '__lds struct gomp_thread * __lds[0]' [-Werror=array-bounds]
  792 |   return *thrs;
      |          ^~~~~

[Bug target/101484] [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[ams at gcc dot gnu.org]

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

Andrew Stubbs <ams at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-07-17

--- Comment #1 from Andrew Stubbs <ams at gcc dot gnu.org> ---
A new warning has been added that falsely identifies any access to a hardcoded
constant address as bogus. This has affected a few targets, including GCN
libgomp. See pr101374.

There's some discussion what to do about it. E.g.
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574880.html

[Bug target/101484] [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msebor at gcc dot gnu.org
   Target Milestone|---                         |12.0
           Priority|P3                          |P1

[Bug target/101484] [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:

https://gcc.gnu.org/g:9f2bc5077debef2b046b6c10d38591ac324ad8b5

commit r12-2392-g9f2bc5077debef2b046b6c10d38591ac324ad8b5
Author: Thomas Schwinge <thomas@codesourcery.com>
Date:   Fri Jul 16 19:12:02 2021 +0200

    [gcn] Work-around libgomp 'error: array subscript 0 is outside array bounds
of â__lds struct gomp_thread * __lds[0]â [-Werror=array-bounds]' [PR101484]

    ... seen as of commit a110855667782dac7b674d3e328b253b3b3c919b "Correct
    handling of variable offset minus constant in -Warray-bounds [PR100137]".

    Awaiting a different solution, of course.

            libgomp/
            PR target/101484
            * config/gcn/team.c: Apply '-Werror=array-bounds' work-around.
            * libgomp.h [__AMDGCN__]: Likewise.

[Bug target/101484] [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Schwinge <tschwinge@gcc.gnu.org>:

https://gcc.gnu.org/g:8168338684fc2bed576bb09202c63b3e9e678d92

commit r12-2408-g8168338684fc2bed576bb09202c63b3e9e678d92
Author: Thomas Schwinge <thomas@codesourcery.com>
Date:   Mon Jul 19 23:11:38 2021 +0200

    [gcn] Work-around libgomp 'error: array subscript 0 is outside array bounds
of â__lds struct gomp_thread * __lds[0]â [-Werror=array-bounds]' some more
[PR101484]

    With yesterday's commit 9f2bc5077debef2b046b6c10d38591ac324ad8b5 "[gcn]
    Work-around libgomp 'error: array subscript 0 is outside array bounds of
    â__lds struct gomp_thread * __lds[0]â [-Werror=array-bounds]'
[PR101484]",
    I did defuse the "unexpected" '-Werror=array-bounds' diagnostics that we
see
    as of commit a110855667782dac7b674d3e328b253b3b3c919b "Correct handling of
    variable offset minus constant in -Warray-bounds [PR100137]".  However,
these
    '#pragma GCC diagnostic [...]' directives cause some code generation
changes
    (that seems unexpected, problematic!), which results in a lot (ten
thousands)
    of 'GCN team arena exhausted' run-time diagnostics, also leading to a few
    FAILs:

        PASS: libgomp.c/../libgomp.c-c++-common/for-11.c (test for excess
errors)
        [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-11.c execution
test

        PASS: libgomp.c/../libgomp.c-c++-common/for-12.c (test for excess
errors)
        [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-12.c execution
test

        PASS: libgomp.c/../libgomp.c-c++-common/for-3.c (test for excess
errors)
        [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-3.c execution
test

        PASS: libgomp.c/../libgomp.c-c++-common/for-5.c (test for excess
errors)
        [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-5.c execution
test

        PASS: libgomp.c/../libgomp.c-c++-common/for-6.c (test for excess
errors)
        [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-6.c execution
test

        PASS: libgomp.c/../libgomp.c-c++-common/for-9.c (test for excess
errors)
        [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-9.c execution
test

    Same for 'libgomp.c++'.

    It remains to be analyzed how '#pragma GCC diagnostic [...]' directives can
    cause code generation changes; for now I'm working around the "unexpected"
    '-Werror=array-bounds' diagnostics differently.

    Overall, still awaiting a different solution, of course.

            libgomp/
            PR target/101484
            * configure.tgt [amdgcn*-*-*] (XCFLAGS): Add
            '-Wno-error=array-bounds'.
            * config/gcn/team.c: Remove '-Werror=array-bounds' work-around.
            * libgomp.h [__AMDGCN__]: Likewise.

[Bug target/101484] [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
Can we close this as fixed?

[Bug target/101484] [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[doko at debian dot org]

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

Matthias Klose <doko at debian dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #5 from Matthias Klose <doko at debian dot org> ---
yes, that builds now

[Bug target/101484] [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |tschwinge at gcc dot gnu.org

--- Comment #6 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #4)
> Can we close this as fixed?

(In reply to Matthias Klose from comment #5)
> yes, that builds now

..., but "fixed" only if you qualify as a proper fix the
'-Wno-error=array-bounds' that I added...  .-\


For the record: I thought it was worth a quick try, but Jakub's recent commit
r12-7713-g32ca611c42658948f1b8883994796f35e8b4e74d "Allow (void *) 0xdeadbeef
accesses without warnings [PR99578]" does not resolve this issue here.

[Bug target/101484] [12 Regression] trunk 20210717 ftbfs for amdgcn-amdhsa (gcn offload)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If it is some special memory address space, would be nice if
targetm.addr_space.zero_address_valid returns true about it.
And in that case, if such a change doesn't fix it, pointer-query.cc or whatever
should take it into account.