[Bug target/60657] New: [4.9 Regression] ICE: error: insn does not satisfy its constraints

[Bug target/60657] New: [4.9 Regression] ICE: error: insn does not satisfy its constraints

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

            Bug ID: 60657
           Summary: [4.9 Regression] ICE: error: insn does not satisfy its
                    constraints
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: doko at gcc dot gnu.org

Created attachment 32452
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32452&action=edit
preprocessed source

seen with trunk r208764 on arm-linux-gnueabihf, works with 4.8 branch.

$ g++ -std=c++11 -c -g -O2 wide_posix_api.ii
In file included from ext/boost/regex/v4/regex.hpp:73:0,
                 from ext/boost/regex.hpp:31,
                 from ext/boost/libs/regex/src/wide_posix_api.cpp:25:
ext/boost/regex/v4/basic_regex_parser.hpp: In member function 'bool
boost::re_detail::basic_regex_parser<charT, traits>::parse_extended_escape()
[with charT = wchar_t; traits = boost::c_regex_traits<wchar_t>]':
ext/boost/regex/v4/basic_regex_parser.hpp:910:1: error: insn does not satisfy
its constraints:
 }
 ^
(insn 3014 3013 3015 227 (set (reg:SI 788 [ D.215148 ])
        (zero_extract:SI (reg:SI 786 [ this_35(D)->D.157694.m_backrefs ])
            (const_int 1 [0x1])
            (const_int 9999 [0x270f])))
ext/boost/regex/v4/basic_regex_parser.hpp:876 149 {extzv_t2}
     (expr_list:REG_DEAD (reg:SI 786 [ this_35(D)->D.157694.m_backrefs ])
        (nil)))
ext/boost/regex/v4/basic_regex_parser.hpp:910:1: internal compiler error: in
extract_constrain_insn_cached, at recog.c:2156
Please submit a full bug report,
with preprocessed source if appropriate.


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9-20140322-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--disable-werror --enable-multilib --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.9.0 20140322 (experimental) [trunk revision 208764] (Ubuntu
4.9-20140322-1ubuntu1)

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[doko at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

--- Comment #1 from Matthias Klose <doko at gcc dot gnu.org> ---
seen with every package using this boost header

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-03-25
                 CC|                            |ramana at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Confirmed.

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

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

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Reduced testcase -O2 -march=armv7-a:
void foo (void);

void
bar (int x, int y)
{
  y = 9999;
  if (x & (1 << y))
    foo ();
}

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note the code isn't invalid, just has undefined behavior.

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
This fixes this for me, based on:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0552a/BABIDBHE.html
If gas accepts some other value beyond those, the conditions can be tweaked of
course, or it could be solved through more tight predicates and/or more
correct/tight constraints (don't see how 0-32 or any power of 2 applies here,
plus the ICE is that const_int_operand + no specific condition allowed combine
to match garbage insn and once you match it with a wrong number, when the
operand doesn't have a register possibility, there is no way to reload it).

Can somebody please test this (together with the testcase, dunno if
-march=armv7-a is tested often enough that the testcase could be just added to
gcc.c-torture/compile/pr60657.c or if you really want to add the -march=armv7-a
option explicitly).  I'd also think that it would be worthwhile to look at all
arm insns with const_int_operand and constraint that doesn't accept all
CONST_INT values and check if it shouldn't be tightened.

--- gcc/config/arm/arm.md.jj    2014-01-03 11:41:20.000000000 +0100
+++ gcc/config/arm/arm.md    2014-03-27 08:53:48.267277083 +0100
@@ -4581,7 +4581,9 @@ (define_insn "*extv_reg"
     (sign_extract:SI (match_operand:SI 1 "s_register_operand" "r")
                          (match_operand:SI 2 "const_int_operand" "M")
                          (match_operand:SI 3 "const_int_operand" "M")))]
-  "arm_arch_thumb2"
+  "arm_arch_thumb2
+   && IN_RANGE (INTVAL (operands[3]), 0, 31)
+   && IN_RANGE (INTVAL (operands[2]), 1, 32 - INTVAL (operands[3]))"
   "sbfx%?\t%0, %1, %3, %2"
   [(set_attr "length" "4")
    (set_attr "predicable" "yes")
@@ -4594,7 +4596,9 @@ (define_insn "extzv_t2"
     (zero_extract:SI (match_operand:SI 1 "s_register_operand" "r")
                          (match_operand:SI 2 "const_int_operand" "M")
                          (match_operand:SI 3 "const_int_operand" "M")))]
-  "arm_arch_thumb2"
+  "arm_arch_thumb2
+   && IN_RANGE (INTVAL (operands[3]), 0, 31)
+   && IN_RANGE (INTVAL (operands[2]), 1, 32 - INTVAL (operands[3]))"
   "ubfx%?\t%0, %1, %3, %2"
   [(set_attr "length" "4")
    (set_attr "predicable" "yes")

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at redhat dot com

--- Comment #6 from Jeffrey A. Law <law at redhat dot com> ---
There's a handful of these that need fixing in the ARM backend, some for the
'M' constraint others for 'I'.

Could you use satisfies_constraint_M and satisfies_constraint_I on the operand?
 At least that way the constraint and the predicate are 100% checking the same
thing.

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
Actually, it occurs to me, why don't we fix the predicates.  That seems like a
better solution than rejecting problematical constants in the insn's condition.

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
Patch is spinning which introduced new predicates which only allow suitable
constants.

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[law at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

--- Comment #9 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Author: law
Date: Fri Apr  4 13:13:20 2014
New Revision: 209085

URL: http://gcc.gnu.org/viewcvs?rev=209085&root=gcc&view=rev
Log:
        PR target/60657
    * config/arm/predicates.md (const_int_I_operand): New predicate.
    (const_int_M_operand): Similarly.
    * config/arm/arm.md (insv_zero): Use const_int_M_operand instead of
    const_int_operand.
    (insv_t2, extv_reg, extzv_t2): Likewise.
    (load_multiple_with_writeback): Similarly for const_int_I_operand.
    (pop_multiple_with_writeback_and_return): Likewise.
    (vfp_pop_multiple_with_writeback): Likewise

    PR target/60657
    * gcc.target/arm/pr60657.c: New test.

Added:
    trunk/gcc/testsuite/gcc.target/arm/pr60657.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/arm/arm.md
    trunk/gcc/config/arm/predicates.md
    trunk/gcc/testsuite/ChangeLog

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

Jeffrey A. Law <law at redhat dot com> changed:

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

--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
Fixed on trunk.

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

--- Comment #11 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Author: ramana
Date: Mon Apr  7 13:17:11 2014
New Revision: 209185

URL: http://gcc.gnu.org/viewcvs?rev=209185&root=gcc&view=rev
Log:
Fix testcase for PR target/60657

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.target/arm/pr60657.c

[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
While the improved predicates make the first IN_RANGE tests unneeded, IMHO it
should still verify what the second IN_RANGE tests did, i.e. that operands[2]
is not 0 and at most 32 - third operand.  I think the combiner just blindly
tries to match and simplify, all the verification is performed through trying
to recog the insn.