[Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints

[Bug target/60606] New: ICE [ARM] error: insn does not satisfy its constraints

[d.salikhov at samsung dot com]

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

            Bug ID: 60606
           Summary: ICE [ARM] error: insn does not satisfy its constraints
           Product: gcc
           Version: 4.8.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: d.salikhov at samsung dot com

Created attachment 32414
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32414&action=edit
Code sample reproducing the bug

Reproduced on 4.8.0+ and on trunk.

*How to reproduce:*
Compile sample code in attachment by "arm-v7a9-linux-gnueabi-gcc -S ice.c"

*Compiler output:*
ice.c: In function 'alpha':
ice.c:5:1: error: insn does not satisfy its constraints:
 }
 ^
(insn 5 2 6 (set (reg:SI 3 r3 [orig:110 pc.0 ] [110])
        (reg/v:SI 15 pc [ pc ])) ice.c:4 641 {*arm_movsi_vfp}
     (nil))
ice.c:5:1: internal compiler error: in note_invalid_constants, at
config/arm/arm.c:13693
0x83e1907 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/rtl-error.c:109
0x83e1945 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/rtl-error.c:120
0x85e4b49 note_invalid_constants
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/config/arm/arm.c:13693
0x85e4b49 arm_reorg
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/config/arm/arm.c:14031
0x83e17b8 rest_of_handle_machine_reorg
   
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/gcc/reorg.c:3939
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



*Commit introducing the bug:*
git hash: bffbb863ff0f267b5111bfa95b42c99cd0474424
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@189350
138bc75d-0d04-0410-961f-82ee72b054a4



arm-v7a9-linux-gnueabi-gcc -v output:

Using built-in specs.
COLLECT_GCC=../../toolchain_repos/ta_sdk/cortex-cross-tools_exp/bin/arm-v7a9-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp/libexec/gcc/arm-v7a9-linux-gnueabi/4.8.3/lto-wrapper
Target: arm-v7a9-linux-gnueabi
Configured with:
/home/salikhov/work/toolchain_repos/ta_sdk/./gcc_experimental/configure
--build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--target=arm-v7a9-linux-gnueabi --disable-libmudflap --disable-libssp
--with-gnu-as --with-gnu-ld --disable-lto --disable-nls
--prefix=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--disable-shared --disable-threads --disable-libssp --disable-libquadmath
--without-headers --with-newlib --disable-decimal-float --disable-libffi
--enable-languages=c
--with-sysroot=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp/arm-v7a9-linux-gnueabi/sys-root/
--with-gmp=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--with-mpfr=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--with-mpc=/home/salikhov/work/toolchain_repos/ta_sdk/cortex-cross-tools_exp
--disable-libgomp --disable-libatomic --with-interwork --with-cpu=cortex-a9
--with-arch=armv7-a --with-mode=arm --with-tune=cortex-a9 --with-fpu=vfpv3
--with-float=softfp
Thread model: single
gcc version 4.8.3 20140321 (prerelease) (GCC)

[Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints

[y.gribov at samsung dot com]

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

Yury Gribov <y.gribov at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |y.gribov at samsung dot com

--- Comment #1 from Yury Gribov <y.gribov at samsung dot com> ---
(In reply to D.Salikhov from comment #0)
> Compile sample code in attachment by "arm-v7a9-linux-gnueabi-gcc -S ice.c"

For my 4.9 with --enable-checking this fails earlier during LRA:

tmp.c: In function 'alpha':
tmp.c:5:1: internal compiler error: in check_rtl, at lra.c:2070
 }
 ^
0x9a3545 check_rtl
    /home/ygribov/src/gcc-master/gcc/lra.c:2070
0x9a3fc7 lra(_IO_FILE*)
    /home/ygribov/src/gcc-master/gcc/lra.c:2449
0x952374 do_reload
    /home/ygribov/src/gcc-master/gcc/ira.c:5457
0x9526c2 rest_of_handle_reload
    /home/ygribov/src/gcc-master/gcc/ira.c:5598
0x95270c execute
    /home/ygribov/src/gcc-master/gcc/ira.c:5627

The problematic RTL seems to be

 (insn 5 2 6 2 (set (reg:SI 3 r3 [orig:110 D.4140 ] [110])
        (reg/v:SI 15 pc [ pc ])) tmp.c:4 663 {*arm_movsi_vfp}
     (nil))

Indeed movsi patterns in arm.md does not allow pc in RHS:

 (define_insn "*arm_movsi_insn"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,r,rk,m")
    (match_operand:SI 1 "general_operand"      "rk, I,K,j,mi,rk"))]

I'm not sure whether this is a bug or a feature. As a workaround you could
simply do

 register unsigned long pc;
 asm("mov %0, pc" : "=r"(pc));

[Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints

[d.salikhov at samsung dot com]

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

--- Comment #2 from D.Salikhov <d.salikhov at samsung dot com> ---
I suppose it is a bug as according to ARM Architecture Reference Manual,
A8.8.13 AND (immediate), pc is valid register for using in 'AND' instruction as
an input.

[Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #3 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
>        register unsigned long pc asm("pc");

I think it's a mistake to permit this sort of construct.  

What does:

  a = pc;
  b = a+pc;

generate for b?  Is it exactly twice a (the compiler doesn't see pc changing,
so is free to assume that it doesn't), just more than twice a (how much more?)
or just less than twice a (different scheduling)?  What happens if the user
writes

  pc = 3; // ???

The point is that while it might be valid to use pc in assembly instructions,
the constructs you get in high-level languages are essentially meaningless.

As has been pointed out, in the few cases where you really need to extract the
program counter you can write an inline assembly statement that explicitly
references the PC.

[Bug target/60606] ICE [ARM] error: insn does not satisfy its constraints

[d.salikhov at samsung dot com]

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

D.Salikhov <d.salikhov at samsung dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WONTFIX                     |---

--- Comment #4 from D.Salikhov <d.salikhov at samsung dot com> ---
(In reply to Richard Earnshaw from comment #3)
> >        register unsigned long pc asm("pc");
> 
> I think it's a mistake to permit this sort of construct.  
> 
> What does:
> 
>   a = pc;
>   b = a+pc;
> 
> generate for b?  Is it exactly twice a (the compiler doesn't see pc
> changing, so is free to assume that it doesn't), just more than twice a (how
> much more?) or just less than twice a (different scheduling)?  What happens
> if the user writes
> 
>   pc = 3; // ???
> 
> The point is that while it might be valid to use pc in assembly
> instructions, the constructs you get in high-level languages are essentially
> meaningless.

Well, even if I use PC incorrectly (actually I don't), it shouldn't lead to
ICE. At least, there should be a sensible error message from compiler but not
internal error.

> 
> As has been pointed out, in the few cases where you really need to extract
> the program counter you can write an inline assembly statement that
> explicitly references the PC.

[Bug target/60606] [ARM] ICE with asm ("mov ...", pc)

[ramana at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
           Priority|P3                          |P5
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-03-27
                 CC|                            |ramana at gcc dot gnu.org
            Summary|ICE [ARM] error: insn does  |[ARM] ICE with asm ("mov
                   |not satisfy its constraints |...", pc)
     Ever confirmed|0                           |1

--- Comment #5 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to D.Salikhov from comment #4)
> (In reply to Richard Earnshaw from comment #3)
> > >        register unsigned long pc asm("pc");
> > 
> > I think it's a mistake to permit this sort of construct.  
> > 
> > What does:
> > 
> >   a = pc;
> >   b = a+pc;
> > 
> > generate for b?  Is it exactly twice a (the compiler doesn't see pc
> > changing, so is free to assume that it doesn't), just more than twice a (how
> > much more?) or just less than twice a (different scheduling)?  What happens
> > if the user writes
> > 
> >   pc = 3; // ???
> > 
> > The point is that while it might be valid to use pc in assembly
> > instructions, the constructs you get in high-level languages are essentially
> > meaningless.
> 
> Well, even if I use PC incorrectly (actually I don't), it shouldn't lead to
> ICE. At least, there should be a sensible error message from compiler but
> not internal error.
> 

True, the compiler shouldn't ICE, but writing an inline assembler statement of
that form, to read the value of the PC is just broken. The value of PC you read
may not be what you expect it to be and allowing such a form is just wrong. It
would be just any old PC. In a function asm ("mov ..., pc") will not give you
the same result relative to other statements in the function all the time.

>From your program it appears as though you want to check Thumbness - is a
static time answer not good enough ? You can get information that from
pre-processor macros.

Anyway, patches welcome if you want to fix it.

[Bug target/60606] [ARM] ICE with asm ("mov ...", pc)

[d.salikhov at samsung dot com]

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

--- Comment #6 from D.Salikhov <d.salikhov at samsung dot com> ---
Created attachment 32817
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32817&action=edit
Yet another code sample

Add less factitious code sample reproducing the issue.

[Bug target/60606] [ARM] ICE with asm ("mov ...", pc)

[jsm28 at gcc dot gnu.org]

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

--- Comment #7 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Author: jsm28
Date: Tue Aug 26 17:06:31 2014
New Revision: 214526

URL: https://gcc.gnu.org/viewcvs?rev=214526&root=gcc&view=rev
Log:
Fix ARM ICE for register var asm ("pc") (PR target/60606).

    PR target/60606
    PR target/61330
    * varasm.c (make_decl_rtl): Clear DECL_ASSEMBLER_NAME and
    DECL_HARD_REGISTER and return for invalid register specifications.
    * cfgexpand.c (expand_one_var): If expand_one_hard_reg_var clears
    DECL_HARD_REGISTER, call expand_one_error_var.
    * config/arm/arm.c (arm_hard_regno_mode_ok): Do not allow
    CC_REGNUM with non-MODE_CC modes.
    (arm_regno_class): Return NO_REGS for PC_REGNUM.

testsuite:
    * gcc.dg/torture/pr60606-1.c, gcc.target/arm/pr60606-2.c,
    gcc.target/arm/pr60606-3.c, gcc.target/arm/pr60606-4.c: New tests.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr60606-1.c
    trunk/gcc/testsuite/gcc.target/arm/pr60606-2.c
    trunk/gcc/testsuite/gcc.target/arm/pr60606-3.c
    trunk/gcc/testsuite/gcc.target/arm/pr60606-4.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/config/arm/arm.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/varasm.c

[Bug target/60606] [ARM] ICE with asm ("mov ...", pc)

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |5.0

--- Comment #8 from Joseph S. Myers <jsm28 at gcc dot gnu.org> ---
Fixed (making this a normal error) for GCC 5.

[Bug target/60606] [ARM] ICE with asm ("mov ...", pc)

[yroux at gcc dot gnu.org]

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

--- Comment #9 from Yvan Roux <yroux at gcc dot gnu.org> ---
Author: yroux
Date: Wed Sep  3 07:23:01 2014
New Revision: 214847

URL: https://gcc.gnu.org/viewcvs?rev=214847&root=gcc&view=rev
Log:
gcc/
2014-09-03  Yvan Roux  <yvan.roux@linaro.org>

    Backport from trunk r214526.
    2014-08-26  Joseph Myers  <joseph@codesourcery.com>

    PR target/60606
    PR target/61330
    * varasm.c (make_decl_rtl): Clear DECL_ASSEMBLER_NAME and
    DECL_HARD_REGISTER and return for invalid register specifications.
    * cfgexpand.c (expand_one_var): If expand_one_hard_reg_var clears
    DECL_HARD_REGISTER, call expand_one_error_var.
    * config/arm/arm.c (arm_hard_regno_mode_ok): Do not allow
    CC_REGNUM with non-MODE_CC modes.
    (arm_regno_class): Return NO_REGS for PC_REGNUM.

gcc/testsuite/
2014-09-03  Yvan Roux  <yvan.roux@linaro.org>

    Backport from trunk r214526.
    2014-08-26  Joseph Myers  <joseph@codesourcery.com>

    PR target/60606
    PR target/61330
    * gcc.dg/torture/pr60606-1.c, gcc.target/arm/pr60606-2.c,
    gcc.target/arm/pr60606-3.c, gcc.target/arm/pr60606-4.c: New tests.


Added:
    branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr60606-1.c
    branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-2.c
    branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-3.c
    branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/pr60606-4.c
Modified:
    branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro
    branches/linaro/gcc-4_9-branch/gcc/cfgexpand.c
    branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.c
    branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro
    branches/linaro/gcc-4_9-branch/gcc/varasm.c