[Bug lto/104868] New: powerpc: Compiling libgfortran with -flto failing with GCC 12

[Bug lto/104868] New: powerpc: Compiling libgfortran with -flto failing with GCC 12

[msc at linux dot ibm.com]

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

            Bug ID: 104868
           Summary: powerpc: Compiling libgfortran with -flto failing with
                    GCC 12
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: msc at linux dot ibm.com
                CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Compiling libgfortran with -flto (see patch [1]) on ppc64le used to work for a
good while until GCC commit r12-7501-g1301d7f647c7ac . Now it fails with:

/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/libgfortran/generated/maxloc0_16_i1.c:
In function 'mmaxloc0_16_i1':
/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/libgfortran/generated/maxloc0_16_i1.c:362:1:
error: insn does not satisfy its constraints:
  362 | }
      | ^
(insn 4106 126 4107 236 (set (reg:V2DI 65 1)
        (vec_duplicate:V2DI (reg:DI 0 0 [1496])))
"/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/libgfortran/generated/maxloc0_16_i1.c":315:36
1477 {vsx_splat_v2di_reg}
     (expr_list:REG_DEAD (reg:DI 0 0 [1496])
        (nil)))
during RTL pass: cprop_hardreg
/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/sources/gcc/libgfortran/generated/maxloc0_16_i1.c:362:1:
internal compiler error: in extract_constrain_insn, at recog.cc:2670
0x7fff8cce171b __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0x7fff8cce18f7 generic_start_main
        ../csu/libc-start.c:392
0x7fff8cce18f7 __libc_start_main_impl
        ../sysdeps/unix/sysv/linux/powerpc/libc-start.c:98
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
lto-wrapper: fatal error:
/home/tcbot/bot-worker/at/src/at16.0-0-alpha.redhat-8_ppc64le_ppc64le/builds/gcc_power10.tuned/./gcc/xgcc
returned 1 exit status
compilation terminated.
/home/tcbot/bot-worker/at_opt/at-next-16.0-0-alpha/powerpc64le-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status

Steps to reproduce on a Power10:

cd gcc
wget
https://raw.githubusercontent.com/powertechpreview/powertechpreview/0be24b142a81e44ac4abadb3fde4eb0010b79f70/GCC%20PowerPC%20Backport/9/gcc-9-lto.patch
patch -p1 < gcc-9-lto.patch

cd build/gcc
CFLAGS=-O2 CXXFLAGS=-O2 CFLAGS_FOR_TARGET=-O3 CXXFLAGS_FOR_TARGET=-O3
~/src/gcc/configure --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu --cache-file=configparms
--prefix=/home/mscastanho/usr --with-long-double-128 --enable-secureplt
--disable-multilib --enable-threads=posix --enable-languages=c,c++,fortran,go
--enable-__cxa_atexit --enable-shared --enable-checking=release
--enable-gnu-indirect-function --enable-lto --enable-linker-build-id
--disable-bootstrap --without-ppl --without-cloog --without-libelf
--with-system-zlib --with-cpu=power10 --with-tune=power10 && make -j60 &>
_make; echo $?


[1]
https://raw.githubusercontent.com/powertechpreview/powertechpreview/0be24b142a81e44ac4abadb3fde4eb0010b79f70/GCC%20PowerPC%20Backport/9/gcc-9-lto.patch

[Bug lto/104868] powerpc: Compiling libgfortran with -flto failing with GCC 12

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

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

--- Comment #1 from Segher Boessenkool <segher at gcc dot gnu.org> ---
operands[1] is "b", but is given GPR 0 here.  The instruction pattern should
handle that case.  Luckily it can just use "r" here.

===
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index b53de1038725..a84ae5df7c0c 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -4576,7 +4576,7 @@ (define_expand "vsx_splat_<mode>"
 (define_insn "vsx_splat_<mode>_reg"
   [(set (match_operand:VSX_D 0 "vsx_register_operand" "=wa,we")
        (vec_duplicate:VSX_D
-        (match_operand:<VS_scalar> 1 "gpc_reg_operand" "wa,b")))]
+        (match_operand:<VS_scalar> 1 "gpc_reg_operand" "wa,r")))]
   "VECTOR_MEM_VSX_P (<MODE>mode)"
   "@
    xxpermdi %x0,%x1,%x1,0
===

Try with that?

[Bug lto/104868] powerpc: Compiling libgfortran with -flto failing with GCC 12

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Well that doesn't do the right thing...  mtvsrdd has RA|0.  So we either need
some third alternative to handle the case it get assigned hard reg 0, or we
should prevent that some other way.

[Bug lto/104868] powerpc: Compiling libgfortran with -flto failing with GCC 12

[segher at gcc dot gnu.org]

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

--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Created attachment 52601
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52601&action=edit
proposed patch

Try the attached, instead?

[Bug lto/104868] powerpc: Compiling libgfortran with -flto failing with GCC 12

[meissner at gcc dot gnu.org]

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

--- Comment #4 from Michael Meissner <meissner at gcc dot gnu.org> ---
In looking at it, the reason is the convert from DImode to TImode has several
constraints.  The constraint that matters in this case has the output being an
Altivec register, while the input is a GPR register.  The vsx_splat_v2di
pattern that is called from the extendidti2 define_insn_and_split has a
constraint of 'b' (i.e. disallow register GPR 0), while the extendidti2 insn
has a constraint of 'r' (i.e. allow any GPR register).

A simple fix is to change the constant in extendditi2 to be 'b' instead of 'r'.

The reason GPR 0 is excluded is the mtvsrdd instruction uses a 0 in the RA
field to indicate put a zero into the upper 64 bits.

[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0
            Summary|powerpc: Compiling          |[12 Regression] powerpc:
                   |libgfortran with -flto      |Compiling libgfortran with
                   |failing with GCC 12         |-flto failing with GCC 12
          Component|lto                         |target
           Keywords|                            |ice-on-valid-code, lto

[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12

[segher at gcc dot gnu.org]

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

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #52601|0                           |1
        is obsolete|                            |

--- Comment #5 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Created attachment 52604
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52604&action=edit
proposed patch

Okay, this then?  It completely disables handling anything that maps to ppc
or ppc64 directly, and leaves those to the mercy of the older code.

[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12

[msc at linux dot ibm.com]

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

--- Comment #6 from Matheus Castanho <msc at linux dot ibm.com> ---
I can still reproduce the issue after applying the patch in previous comment.

[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12

[meissner at gcc dot gnu.org]

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

Michael Meissner <meissner at gcc dot gnu.org> changed:

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

--- Comment #7 from Michael Meissner <meissner at gcc dot gnu.org> ---
Created attachment 52610
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52610&action=edit
Patch to fix extendidti2 constraint on power10

[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12

[meissner at gcc dot gnu.org]

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

--- Comment #8 from Michael Meissner <meissner at gcc dot gnu.org> ---
Matheus, try the patch I just attached to the PR that I posted to the
gcc-patches mailing list.

[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12

[msc at linux dot ibm.com]

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

--- Comment #9 from Matheus Castanho <msc at linux dot ibm.com> ---
That one works. Thanks!

[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:3cb27b85a7b977958d53e1a29596ba211d21dde2

commit r12-7620-g3cb27b85a7b977958d53e1a29596ba211d21dde2
Author: Michael Meissner <meissner@linux.ibm.com>
Date:   Fri Mar 11 19:47:09 2022 -0500

    Fix DImode to TImode sign extend issue

    PR target/104868 had had an issue where my code that updated the DImode to
    TImode sign extension for power10 failed.  In looking at the failure
    message, the reason is when extendditi2 tries to split the insn, it
    generates an insn that does not satisfy its constraints:

            (set (reg:V2DI 65 1)
                 (vec_duplicate:V2DI (reg:DI 0)))

    The reason is vsx_splat_v2di does not allow GPR register 0 when the will
    be generating a mtvsrdd instruction.  In the definition of the mtvsrdd
    instruction, if the RA register is 0, it means clear the upper 64 bits of
    the vector instead of moving register GPR 0 to those bits.

    When I wrote the extendditi2 pattern, I forgot that mtvsrdd had that
    behavior so I used a 'r' constraint instead of 'b'.  In the rare case
    where the value is in GPR register 0, this split will fail.

    This patch uses the right constraint for extendditi2.

    2022-03-11   Michael Meissner  <meissner@linux.ibm.com>

    gcc/
            PR target/104868
            * config/rs6000/vsx.md (extendditi2): Use a 'b' constraint when
            moving from a GPR register to an Altivec register.

[Bug target/104868] [12 Regression] powerpc: Compiling libgfortran with -flto failing with GCC 12

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Assuming this is fixed, if not, please reopen.