[Bug target/66358] New: [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[Bug target/66358] New: [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[kkojima at gcc dot gnu.org]

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

            Bug ID: 66358
           Summary: [5/6 Regression] [SH] ICE: in extract_constrain_insn,
                    at recog.c:2232
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kkojima at gcc dot gnu.org
                CC: olegendo at gcc dot gnu.org
  Target Milestone: ---
            Target: sh*-*-*

On sh4-unknown-linux-gnu, gcc5/6 fails to compile libiberty/regex.c
with -O2 -fpic:

libiberty/regex.c: In function 'byte_re_match_2_internal':
libiberty/regex.c:7486:1: error: insn does not satisfy its constraints:
(insn 14303 10571 14304 388 (set (reg:SI 2 r2)
        (sign_extend:SI (mem:QI (plus:SI (reg/f:SI 6 r6 [orig:794 D.8765 ]
[794])
                    (const_int 5 [0x5])) [0 MEM[(unsigned char *)_1000 + 5B]+0
S1 A8]))) libiberty/regex.c:7109 232 {*extendqisi2_compact_mem_disp}
     (nil))
libiberty/regex.c:7486:1: internal compiler error: in extract_constrain_insn,
at recog.c:2232
0x86d443f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        ../../ORIG/trunk/gcc/rtl-error.c:110
0x86d4475 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
        ../../ORIG/trunk/gcc/rtl-error.c:121
0x86a0835 extract_constrain_insn(rtx_insn*)
        ../../ORIG/trunk/gcc/recog.c:2232
0x86a3b29 copyprop_hardreg_forward_1
        ../../ORIG/trunk/gcc/regcprop.c:788
0x86a4877 execute
        ../../ORIG/trunk/gcc/regcprop.c:1283

There is no problem with gcc-4.9.x.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[kkojima at gcc dot gnu.org]

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

--- Comment #1 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 35661
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35661&action=edit
reduced test case

FYI, it doesn't fail with -O2 -fpic -mlra.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> ---
There was this idea of doing some sort of pre-reg-alloc or special case
handling for R0 in an SH specific RTL pass before regular RA -- see PR 64785.

One option could be to have a simple version of that pass for GCC 5 to fix this
PR (and maybe several other of this kind).  For GCC 6 we could probably just
add -mno-lra option and make -mlra the default setting.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #2)

Defaulting -mlra might be reasonable for gcc 6.
For gcc 5, I thought the patch for prepare_move_operands like

diff --git a/config/sh/sh.c b/config/sh/sh.c
index 1cf6ed0..b855d70 100644
--- a/config/sh/sh.c
+++ b/config/sh/sh.c
@@ -1789,9 +1789,8 @@ prepare_move_operands (rtx operands[], machine_mode mode)
         target/55212.
         We split possible load/store to two move insns via r0 so as to
         shorten R0 live range.  It will make some codes worse but will
-        win on avarage for LRA.  */
-      else if (sh_lra_p ()
-              && TARGET_SH1 && ! TARGET_SH2A
+        win on avarage.  */
+      else if (TARGET_SH1 && ! TARGET_SH2A
               && (mode == QImode || mode == HImode)
               && ((REG_P (operands[0]) && MEM_P (operands[1]))
                   || (REG_P (operands[1]) && MEM_P (operands[0]))))

which would be a simplest form of the preallocating r0 for this limited case,
though I'm afraid that it's still too invasive for the release branch.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |5.2

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #1)
> Created attachment 35661 [details]
> reduced test case
> 
> FYI, it doesn't fail with -O2 -fpic -mlra.

Somehow the reduced test case seems to work OK on sh-elf even without -mlra.

sh-elf-gcc -v
Using built-in specs.
COLLECT_GCC=sh-elf-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/sh-elf/6.0.0/lto-wrapper
Target: sh-elf
Configured with: ../gcc-trunk/configure --target=sh-elf --prefix=/usr/local
--enable-languages=c,c++ --enable-multilib --enable-libssp --disable-nls
--disable-werror --enable-lto --with-newlib --with-system-zlib
Thread model: single
gcc version 6.0.0 20150521 (experimental) (GCC) 

Maybe I'm missing some option?

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
Created attachment 35673
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35673&action=edit
original test case

My sh-elf compiler

COLLECT_GCC=../xsh-elf-combined/build/gcc/xgcc
Target: sh-unknown-elf
Configured with: /exp/ldroot/dodes/xsh-elf-combined/combined/configure
--target=sh-unknown-elf --disable-libssp --disable-libgomp
--disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --enable-languages=c,c++
--disable-shared --with-newlib --disable-nls
--prefix=/exp/ldroot/dodes/xsh-elf-combined/install --with-headers=yes
--disable-gdbtk --with-mpfr=/opt2/i686-pc-linux-gnu
--with-gmp=/opt2/i686-pc-linux-gnu --without-libgloss
Thread model: single
gcc version 6.0.0 20150531 (experimental) (GCC) 

can reproduce it with -O2 -fpic -m4 -ml, though the bug looks a bit
fragile like as other RA related bugs.  I've attached unreduced test
case.  sh-elf compiler ICEs for this test case even with -O2 only here.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[olegendo at gcc dot gnu.org]

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

--- Comment #6 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #3)
> (In reply to Oleg Endo from comment #2)
> 
> Defaulting -mlra might be reasonable for gcc 6.
> For gcc 5, I thought the patch for prepare_move_operands like
> 
> diff --git a/config/sh/sh.c b/config/sh/sh.c
> index 1cf6ed0..b855d70 100644
> --- a/config/sh/sh.c
> +++ b/config/sh/sh.c
> @@ -1789,9 +1789,8 @@ prepare_move_operands (rtx operands[], machine_mode
> mode)
>          target/55212.
>          We split possible load/store to two move insns via r0 so as to
>          shorten R0 live range.  It will make some codes worse but will
> -        win on avarage for LRA.  */
> -      else if (sh_lra_p ()
> -              && TARGET_SH1 && ! TARGET_SH2A
> +        win on avarage.  */
> +      else if (TARGET_SH1 && ! TARGET_SH2A
>                && (mode == QImode || mode == HImode)
>                && ((REG_P (operands[0]) && MEM_P (operands[1]))
>                    || (REG_P (operands[1]) && MEM_P (operands[0]))))
> 
> which would be a simplest form of the preallocating r0 for this limited case,
> though I'm afraid that it's still too invasive for the release branch.

There could be some negative side effects with the patch above, because it
forces the R0 usage quite early (at RTL expansion).

I'd like to give the RTL pass a try, although it's probably even more invasive
than the patch above.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[kkojima at gcc dot gnu.org]

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

--- Comment #7 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #6)
> There could be some negative side effects with the patch above, because it
> forces the R0 usage quite early (at RTL expansion).

Yes, the comment part says it and it was discussed in #c83
and #c82 of PR55212.  This patch will be a 'micro-degradation',
though it wins CSiBE for the code size at least, even without LRA.

> I'd like to give the RTL pass a try, although it's probably even more
> invasive than the patch above.

It sounds better and OK for trunk.  Also yes, it looks too invasive
for the release branch.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[olegendo at gcc dot gnu.org]

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

--- Comment #8 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #7)
> (In reply to Oleg Endo from comment #6)
> > There could be some negative side effects with the patch above, because it
> > forces the R0 usage quite early (at RTL expansion).
> 
> Yes, the comment part says it and it was discussed in #c83
> and #c82 of PR55212.  This patch will be a 'micro-degradation',
> though it wins CSiBE for the code size at least, even without LRA.

Ah, right.  If it fixes the problem, then I think it's the only option we have
for the release branch.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[olegendo at gcc dot gnu.org]

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

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glaubitz at physik dot fu-berlin.d
                   |                            |e

--- Comment #9 from Oleg Endo <olegendo at gcc dot gnu.org> ---
*** Bug 66395 has been marked as a duplicate of this bug. ***

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[kkojima at gcc dot gnu.org]

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

--- Comment #10 from Kazumoto Kojima <kkojima at gcc dot gnu.org> ---
(In reply to Oleg Endo from comment #8)
> Ah, right.  If it fixes the problem, then I think it's the only option we
> have for the release branch.

It can be used as a last resort.  It depends on whether various rtl
passes take care of hard registers or not.
I'd like to wait your pre-allocating pass.  It's surely cleaner than
that a bit unreliable artifact in prepare_move_operands.  Perhaps
both can be almost equaly invasive to the release branch.  If the pass
is enough simple and can give good results, it may be a safer bet,
especially when we are in transition to LRA.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #11 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Any news on this issue? The sh4 buildds in Debian are currently building a
snapshot as of 2015-06-13 (r224454), let's see how far it gets.

Adrian

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo <olegendo at gcc dot gnu.org> ---
It seems the problem is adjacent insns that need R0:

(insn 10503 2627 2628 402 (set (reg:SI 2424)
        (sign_extend:SI (mem:QI (plus:SI (reg/v/f:SI 243 [ p2 ])
                    (const_int 2 [0x2])) [0 MEM[(unsigned char *)p2_97 + 2B]+0
S1 A8]))) ../../ORIG/trunk/libiberty/regex.c:7109 232
{*extendqisi2_compact_mem_disp}
     (nil))
(note 2628 10503 10505 402 NOTE_INSN_DELETED)
(insn 10505 2628 2629 402 (set (reg:SI 2425)
        (sign_extend:SI (mem:QI (plus:SI (reg/f:SI 774 [ D.8751 ])
                    (const_int 5 [0x5])) [0 MEM[(unsigned char *)_1000 + 5B]+0
S1 A8]))) ../../ORIG/trunk/libiberty/regex.c:7109 232
{*extendqisi2_compact_mem_disp}
     (nil))
(note 2629 10505 2631 402 NOTE_INSN_DELETED)
(note 2631 2629 10507 402 NOTE_INSN_DELETED)
(insn 10507 2631 2633 402 (set (reg:SI 147 t)
        (eq:SI (and:SI (reg:SI 2424)
                (reg:SI 2425))
            (const_int 0 [0]))) ../../ORIG/trunk/libiberty/regex.c:7109 1
{tstsi_t}
     (expr_list:REG_DEAD (reg:SI 2425)
        (expr_list:REG_DEAD (reg:SI 2424)
            (nil))))

In insn 10503 reg 2424 will be allocated to R0 and will remain live until insn
10507.  Reload then fails to insert a move insn R0 -> other reg after insn
10503 and R0 allocation for insn 10505 becomes impossible.  I've observed this
issue already a while ago.  I think this condition can be improved using some
sort of linear register allocator for R0-insns.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[dcb314 at hotmail dot com]

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

--- Comment #16 from David Binderman <dcb314 at hotmail dot com> ---
Created attachment 36167
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36167&action=edit
C source code

[Bug target/66358] [5/6 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[dcb314 at hotmail dot com]

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

--- Comment #17 from David Binderman <dcb314 at hotmail dot com> ---
I had a go at cross compiling Linux kernel for sh, and got something similar
with gcc 5.1.1 dated 20150618

$ sh-linux-gnu-gcc -c -O2 bug224.c
drivers/hwmon/w83627ehf.c: In function ‘show_caseopen’:
drivers/hwmon/w83627ehf.c:1774:1: error: insn does not satisfy its constraints:
(insn 135 111 136 2 (set:SI (reg:SI 1 r1)
        (sign_extend:SI (mem:QI (plus:SI (reg/f:SI 8 r8 [175])
                    (const_int 12 [0xc])) [0 MEM[(struct
sensor_device_attribute_2 *)attr_6(D)].index+0 S1 A32])))
drivers/hwmon/w83627ehf.c:1772 231 {*extendqisi2_compact_mem_disp}
     (nil))
drivers/hwmon/w83627ehf.c:1774:1: internal compiler error: in
extract_constrain_insn, at recog.c:2246

Problem seems to go away when I add flag -mlra, so I have a workaround.

Test case attached.
>From gcc-bugs-return-494543-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Aug 11 07:57:37 2015
Return-Path: <gcc-bugs-return-494543-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14129 invoked by alias); 11 Aug 2015 07:57:37 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14091 invoked by uid 48); 11 Aug 2015 07:57:33 -0000
From: "63877278 at qq dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/67180] New: Gccgo does not support MIPS
Date: Tue, 11 Aug 2015 07:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: 63877278 at qq dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone cf_gcchost cf_gcctarget
Message-ID: <bug-67180-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00685.txt.bz2
Content-length: 540

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg180

            Bug ID: 67180
           Summary: Gccgo does not support MIPS
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: go
          Assignee: ian at airs dot com
          Reporter: 63877278 at qq dot com
                CC: 63877278 at qq dot com, cmang at google dot com
  Target Milestone: ---
              Host: mips64
            Target: mips64

Gccgo does not support MIPS

[Bug target/66358] [9/10/11/12 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug target/66358] [9/10/11/12 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug target/66358] [10/11/12/13 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #30 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug target/66358] [10/11/12/13 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug target/66358] [11/12/13/14 Regression] [SH] ICE: in extract_constrain_insn, at recog.c:2232

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.