[Bug target/96306] New: gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[Bug target/96306] New: gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[tschwinge at gcc dot gnu.org]

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

            Bug ID: 96306
           Summary: gcn libgomp build broken after "libomp: Add
                    omp_depend_kind to omp_lib.{f90,h}"
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Keywords: openacc, openmp
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tschwinge at gcc dot gnu.org
                CC: ams at gcc dot gnu.org, burnus at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, jules at gcc dot gnu.org
  Target Milestone: ---
            Target: gcn

After commit 2631d95ae29dc6a0f5bda4af1f6595a17b1efbfd "libomp: Add
omp_depend_kind to omp_lib.{f90,h}":

    configure: error: unsupported system, cannot find Fortran int kind=16,
needed for omp_depend_kind
    Makefile:15426: recipe for target 'configure-target-libgomp' failed
    make[1]: *** [configure-target-libgomp] Error 1

Is this another instance of the "'TImode' problem" indicated in PR95730 'GCN
offloading ICEs after commit fe7ebef7fe4f9acb79658ed9db0749b07efc3105 "Add
support for __builtin_bswap128"', or is it something else?

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Unlike non-offloading targets where there is always an option to just use
smaller omp_depend_kind and instead treat it as pointer to malloced struct and
free at the end, like done on some targets for locks, for offloading targets
I'm afraid this is problematic, because the sources will really use 16-byte
omp_depend_kind anyway on most of the lp64 hosts.

So, what are the obstackles to support TImode on gcn?

After all, users can just use __int128_t etc. in their programs too.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Just as background: While OpenMP uses for C/C++ a typedef for 'omp_depend_t',
which maps to a struct with "char[2*sizeof(*void)]", for Fortran an integer
kind is required by the OpenMP spec.
At least with the current implementation for 'dep' this means a 128bit/kind=16
for a 64bit-pointer system.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[ams at gcc dot gnu.org]

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

--- Comment #3 from Andrew Stubbs <ams at gcc dot gnu.org> ---
TImode was added for use by a few instructions that take two 64-bit values in
consecutive registers. It's also useful for the SLP fake vectorization stuff.

It wasn't intended for use with user types; I probably ought to disable it, at
least for now.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Most targets don't have 128-bit GPR instructions, either none at all, or most
of them.  That doesn't mean it isn't easy to support it, for the simpler
operations like basic arithmetics, if there is no optab for those, the
middle-end (well, expander) should DTRT and expand those already, and for more
complex stuff there is always libgcc that has the double word support in there.
 I think the backend needs to have at least movti optab.
Of course, it helps if the backend tries to help a little bit, e.g. for TImode
plus/minus it is nice to have some carry  into the second addition or similar.
For the omp_depend_kind itself, even no arithmetic support is probably needed.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[ams at gcc dot gnu.org]

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

--- Comment #5 from Andrew Stubbs <ams at gcc dot gnu.org> ---
GCC will automatically generate libgcc calls for types up to 2*BITS_PER_WORD,
but no further. Since BITS_PER_WORD is 32 on GCN this means no automatic TImode
support for anything that would go that route (such as div).

If I enable TImode in scalar_mode_supported_p then libgomp is happy, but
libgfortran will automatically try to generate runtime functions to make use of
it. These inevitably trigger an ICE whenever an unavailable optab is
encountered.

These are solvable problems, but I don't have the engineering resource right
now to go build out full TImode support.

Is there some other way we can make libgomp work?

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Only by slowing down all 64-bit targets in OpenMP for Fortran by using the
indirection (and make it incompatible with C/C++ too, which is even worse).
I wasn't aware that gcn is BITS_PER_WORD 32 target, that makes it indeed
harder, but for an offloading target that wants to support 64-bit host targets
I'm afraid the extra work is needed, because user can use the kind=16 or
__int128_t types in their code.
It can be minimal support, e.g. just have addti3, subti3, {and,ior,xor}ti3,
shifts and a few others just as expanders that lower it immediately to DImode
code, and for other operations defer to library.
libgcc2.[ch] I think can be convinced through macros to emit code for TImode
implementation using DImode, or you have e.g. config/gcn/lib2-divmod.c that
could be adjusted into lib2-divmodti.c.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
At least as in-between solution, one could change libgfortran to disable
HAVE_GFC_INTEGER_16 for gcn. — libgfortran exercises a lot of the integer
arithmetics, which we do not need here.
One just needs to ensure that mk-kinds-h.sh (and possibly mk-sik-inc.sh and
mk-srk-inc.sh) does not check for "16" (in possible_integer_kinds).
That could be done in a similar way as done for LIBGFOR_MINIMAL in configure.ac
and passing an argument to the script in Makefile*.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[ams at gcc dot gnu.org]

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

--- Comment #8 from Andrew Stubbs <ams at gcc dot gnu.org> ---
I'm loath to enable TImode if it's going to ICE all over the place, and I can't
just drop everything else and implement working TImode unless there's an easy
solution. It's always been on the nice-to-have list, but never high priority.

Aside from the OpenMP spec, is there any reason why this can't be implemented
as some kind of aggregate type? At least for now?

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Initial TI support for AMDGCN has been committed, see:
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550663.html
https://gcc.gnu.org/g:8d0b2b33748014ee57973c1d7bc9fd7706bb3da9

commit 8d0b2b33748014ee57973c1d7bc9fd7706bb3da9
Author: Andrew Stubbs <ams@codesourcery.com>
Date:   Sat Jul 25 15:02:52 2020 +0100

    amdgcn: Enable TImode

    This enables types __int128 et al for move, add, subtract, and logical
    operations.  At least shift, rotate, multiple, divide, and modulus are
broken
    so we can expect some test failures.

    This is required now because libgomp no longer builds without __int128.

    An additional patch will be required to unbreak the libgfortran build.

    gcc/ChangeLog:

            * config/gcn/gcn.c (gcn_scalar_mode_supported_p): New function.
            (TARGET_SCALAR_MODE_SUPPORTED_P): New define.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tobias Burnus <burnus@gcc.gnu.org>:

https://gcc.gnu.org/g:2e764ae1d666002b136726e6548481013527197d

commit r11-2328-g2e764ae1d666002b136726e6548481013527197d
Author: Tobias Burnus <tobias@codesourcery.com>
Date:   Sun Jul 26 07:20:24 2020 +0200

    libgfortran: Skip integer-kind=16 check for amdgcn

    libgfortran/ChangeLog:

            PR target/96306
            * configure.ac: Add LIBGOMP_CHECKED_INT_KINDS and
            LIBGOMP_CHECKED_REAL_KINDS and use it for to skip
            integer kind=16 checks for amdgcn.
            * Makefile.am (kinds.h, selected_int_kind.inc,
            selected_real_kind.inc): Pass them on.
            * mk-kinds-h.sh: Takes to-be-check kinds as argument.
            * mk-sik-inc.sh: Likewise.
            * mk-srk-inc.sh: Likewise.
            * Makefile.in: Regenerate.
            * configure: Regenerate.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[tschwinge at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-07-27

--- Comment #11 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
I'm confirming that the libgomp build failure originally reported is gone --
thanks, Andrew and Tobias!

I suppose we want to keep this one open for the gcn back end to be further
changed so that the libgfortran workaround can eventually be reverted.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.0                        |11.2

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.1 has been released, retargeting bugs to GCC 11.2.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Julian Brown <jules@gcc.gnu.org>:

https://gcc.gnu.org/g:c0f8c22a3e9f8cd45c1cb4be5f83afbebe3bfdc9

commit r12-1911-gc0f8c22a3e9f8cd45c1cb4be5f83afbebe3bfdc9
Author: Julian Brown <julian@codesourcery.com>
Date:   Fri Jun 11 14:44:36 2021 -0700

    Fortran: Re-enable 128-bit integers for AMD GCN

    This patch reverts the part of Tobias's patch for PR target/96306 that
    disables 128-bit integer support for AMD GCN.

    2021-06-18  Julian Brown  <julian@codesourcery.com>

    libgfortran/
            PR target/96306
            * configure.ac: Remove stanza that removes KIND=16 integers for AMD
GCN.
            * configure: Regenerate.

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|11.2                        |---

[Bug target/96306] gcn libgomp build broken after "libomp: Add omp_depend_kind to omp_lib.{f90,h}"

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #14 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Close as FIXED in GCC 12/mainline.

Support for __int128 / integer(kind=16) / TI mode is available –
and libgfortran's __int128-disable patch for GCN has been reverted.