[Bug rtl-optimization/103170] New: ICE: output_operand: incompatible floating point / vector register operand for '%s'

[Bug rtl-optimization/103170] New: ICE: output_operand: incompatible floating point / vector register operand for '%s'

[asolokha at gmx dot com]

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

            Bug ID: 103170
           Summary: ICE: output_operand: incompatible floating point /
                    vector register operand for '%s'
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: asolokha at gmx dot com
  Target Milestone: ---
            Target: aarch64-linux-gnu

gfortran-12.0.0-alpha20211107 snapshot
(g:962ff7d2849e1fa6a1fe0535aa2dec5c2b9a32a6) ICEs when compiling the following
testcase, extracted from gcc/testsuite/gfortran.dg/loop_versioning_4.f90, w/
-O3 -fselective-scheduling2 -ftree-parallelize-loops=2 -fno-tree-ch:

subroutine f5(x, n, limit, step)
  integer :: n, limit, step
  real :: x(limit, n)
  do i = 1, n
     do j = 1, limit, step
        x(j, i) = 100
     end do
  end do
end subroutine f5

% aarch64-linux-gnu-gfortran-12.0.0 -O3 -fselective-scheduling2
-ftree-parallelize-loops=2 -fno-tree-ch -c hxpbnms6.f90
during RTL pass: final
hxpbnms6.f90:9:17:

    9 | end subroutine f5
      |                 ^
internal compiler error: output_operand: incompatible floating point / vector
register operand for '%s'
0xc1d5fc output_operand_lossage(char const*, ...)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/final.c:3235
0xc1d7df output_operand(rtx_def*, int)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/final.c:3677
0xc1e506 output_asm_insn(char const*, rtx_def**)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/final.c:3570
0xc1e506 output_asm_insn(char const*, rtx_def**)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/final.c:3453
0xc2258f final_scan_insn_1
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/final.c:2894
0xc2294b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/final.c:2940
0xc22a36 final_1
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/final.c:1997
0xc23711 rest_of_handle_final
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/final.c:4285
0xc23711 execute
       
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20211107/work/gcc-12-20211107/gcc/final.c:4363

BTW, looking at existing selective scheduler related PRs, I can see a pattern
involving -fselective-scheduling{,2} -fno-tree-ch.

[Bug target/103170] ICE: output_operand: incompatible floating point / vector register operand for '%s'

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-11-10
     Ever confirmed|0                           |1

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(insn 312 277 365 (set (reg:V4SF 32 v0 [179])
        (vec_duplicate:V4SF (reg:SF 4 x4 [185]))) 1129 {aarch64_simd_dupv4sf}
     (nil))


#7  0x0000000000a583e4 in output_asm_insn (templ=0x1f1f7f0 "dup\t%0.4s, %s1",
operands=0x24f6760 <recog_data>) at
/home/ubuntu/src/upstream-gcc-aarch64/gcc/gcc/final.c:3570


(define_insn "aarch64_simd_dup<mode>"
  [(set (match_operand:VDQF_F16 0 "register_operand" "=w,w")
        (vec_duplicate:VDQF_F16
          (match_operand:<VEL> 1 "register_operand" "w,r")))]
  "TARGET_SIMD"
  "@
   dup\\t%0.<Vtype>, %1.<Vetype>[0]
   dup\\t%0.<Vtype>, %<vw>1"
  [(set_attr "type" "neon_dup<q>, neon_from_gp<q>")]

;; Define corresponding core/FP element mode for each vector mode.
(define_mode_attr vw [(V8QI "w") (V16QI "w")
                      (V4HI "w") (V8HI "w")
                      (V2SI "w") (V4SI "w")
                      (DI   "x") (V2DI "x")
                      (V2SF "s") (V4SF "s")
                      (V2DF "d")])

Confirmed. This is definitely a target issue. The asm template is wrong, it
should be vwcore instead.

;; Corresponding core element mode for each vector mode.  This is a
;; variation on <vw> mapping FP modes to GP regs.
(define_mode_attr vwcore [(V8QI "w") (V16QI "w")
                          (V4HI "w") (V8HI "w")
                          (V2SI "w") (V4SI "w")
                          (DI   "x") (V2DI "x")
                          (V4HF "w") (V8HF "w")
                          (V4BF "w") (V8BF "w")
                          (V2SF "w") (V4SF "w")
                          (V2DF "x")
                          (VNx16QI "w") (VNx8QI "w") (VNx4QI "w") (VNx2QI "w")
                          (VNx8HI "w") (VNx4HI "w") (VNx2HI "w")
                          (VNx8HF "w") (VNx4HF "w") (VNx2HF "w")
                          (VNx8BF "w") (VNx4BF "w") (VNx2BF "w")
                          (VNx4SI "w") (VNx2SI "w")
                          (VNx4SF "w") (VNx2SF "w")
                          (VNx2DI "x")
                          (VNx2DF "x")])

I will see if changing will fix it.

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE: output_operand:        |[12 Regression] ICE:
                   |incompatible floating point |output_operand:
                   |/ vector register operand   |incompatible floating point
                   |for '%s'                    |/ vector register operand
                   |                            |for '%s'
   Target Milestone|---                         |12.0

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Here is a GNU C testcase which shows the error:
#define vector __attribute__((vector_size(4*sizeof(float))))

typedef vector float v4sf;

v4sf f(int t)
{
  float tt = *(float*)&t;
  float t1 = tt;
  asm("":"+r"(t1));
  return (v4sf){t1,t1,t1,t1};
}

And it shows it is a regression from GCC 11 too.

Also vwcore fixes the issue.

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The problem was caused by r12-4828 which added that alternative.

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 51761
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51761&action=edit
Patch which I will be committing

Patch which I will be committing once I finish testing it.

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

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

commit r12-5137-gc744ae0897957def0cd798399ef8ed6dc0d23811
Author: Andrew Pinski <apinski@marvell.com>
Date:   Wed Nov 10 18:37:22 2021 +0000

    [COMMITTED] aarch64: [PR103170] Fix aarch64_simd_dup<mode>

    The problem here is aarch64_simd_dup<mode> use
    the vw iterator rather than vwcore iterator.  This causes
    problems for the V4SF and V2DF modes. I changed both of
    aarch64_simd_dup<mode> patterns to be consistent.

    Committed as obvious after a bootstrap/test on aarch64-linux-gnu.

            PR target/103170

    gcc/ChangeLog:

            * config/aarch64/aarch64-simd.md (aarch64_simd_dup<mode>):
            Use vwcore iterator for the r constraint output string.

    gcc/testsuite/ChangeLog:

            * gcc.c-torture/compile/vector-dup-1.c: New test.

[Bug target/103170] [12 Regression] ICE: output_operand: incompatible floating point / vector register operand for '%s'

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed, thanks for the report.