[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[dsd at laptop dot org]

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

Daniel Drake <dsd at laptop dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsd at laptop dot org

--- Comment #30 from Daniel Drake <dsd at laptop dot org> 2012-09-03 22:29:08 UTC ---
Reproduced this on gcc-4.7.1 when building glibc with -march=iwmmxt

gconv_cache.c: In function '__gconv_lookup_cache':
gconv_cache.c:448:1: error: insn does not satisfy its constraints:
(insn 1192 1127 433 38 (set (reg/f:SI 13 sp)
        (reg/f:SI 43 wcgr0 [611])) 499 {*iwmmxt_movsi_insn}
     (expr_list:REG_ARGS_SIZE (const_int 0 [0])
        (nil)))
gconv_cache.c:448:1: internal compiler error: in reload_cse_simplify_operands,
at postreload.c:403

Probably unsuprisingly, backporting the iwmmxt2 support from gcc 4.8 to 4.7 and
compiling with -march=iwmmxt2 produces the same result.

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[dsd at laptop dot org]

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

--- Comment #31 from Daniel Drake <dsd at laptop dot org> 2012-09-11 19:11:27 UTC ---
Created attachment 28173
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28173
preprocessed source that crashes

Another preprocessed source example that shows this crasher, from glibc
gconv_cache compilation. Compile with: gcc -march=iwmmxt -O3 -c test.c

Note: -O3 is needed to cause the crash, with -O2 it compiles OK.

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[dsd at laptop dot org]

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

--- Comment #32 from Daniel Drake <dsd at laptop dot org> 2012-09-19 21:02:55 UTC ---
Using the preprocessed source that I attached, I can't reproduce this with
gcc-4.8 head (my previous test was with 4.7.x). Also, I have completed a glibc
compile with -march=iwmmxt2 on gcc-4.8.

So I think this bug may have been solved post-gcc-4.7.

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[jackie.rosen at hushmail dot com]

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

Jackie Rosen <jackie.rosen at hushmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jackie.rosen at hushmail dot com

--- Comment #33 from Jackie Rosen <jackie.rosen at hushmail dot com> ---
*** Bug 260998 has been marked as a duplicate of this bug. ***
Seen from the domain http://volichat.com
Page where seen: http://volichat.com/adult-chat-rooms
Marked for reference. Resolved as fixed @bugzilla.

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[ramana at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |ramana at gcc dot gnu.org

--- Comment #34 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
I guess waiting till someone tests on iwmmxt2 or proposes an actual tested
patch for this on trunk.

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[ian dot bolton at arm dot com]

------- Comment #29 from ian dot bolton at arm dot com  2010-07-09 17:02 -------
(In reply to comment #7)
> When I read the RTL dumps correctly, gcc tries to assign SP to wCGR0.

SP is actually the destination here, not the source.  

> This can be done by the
> 
>     tmrc  sp, wCGR0
> 
> assembly instruction which will be issued by alternative 6 in
> 
> 
> --- iwmmxt.md ---
> (define_insn "*iwmmxt_movsi_insn"
>   [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk, m,z,r,?z,Uy,z")
>         (match_operand:SI 1 "general_operand"      "rk, I,K,mi,rk,r,z,Uy,z,
> z"))]
>    ...
>    case 6: return \"tmrc\\t%0, %1\";
> 
> 
> The corresponding constraints pair is ['r', 'z'] and it is matched by
> [sp, wcgr0] afais.  What could be the reason for the ICE?
> 

As existing replies already point out, the ICE is being caused by the fact that
SP does not meet the "r" constraint (you need "k" to specify SP).  However, if
the constraint were valid, and the assignment to SP was allowed to occur, you
would essentially be using SP as a general purpose register when it is special
and should not be used this way.

Based on my limited (so far) understanding of the ARM port of GCC, I think the
fault lies either with the predicate (nonimmediate_operand), which is allowing
SP to be the dest, or the code that created the iwmmxt_movsi_insn with SP as
its dest.  There was a time (before Thumb-2, I think) when SP could be used as
a general purpose register, so maybe some IWMMXT-related code needs updating to
reflect this.


-- 

ian dot bolton at arm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian dot bolton at arm dot
                   |                            |com


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #28 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-11-28 23:08 -------
Created an attachment (id=19173)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19173&action=view)
arm-linux-gnueabi-gcc -march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt -std=gnu99 -c
-O2 libc_fatal.i

Patch generates inefficient code; e.g. it emits now

     568:       ee183110        tmrc    r3, wcgr0
     56c:       e1a0d003        mov     sp, r3

which could be written directly as

     tmrc   sp, wcgr0

when allowing a ['rk','z'] constraint.


The new ICE mentioned in comment #20 still happens with this patch. But this
seems to be a dup of bug #37987 which exists for earlier gcc versions too.  I
attached a testcase for completeness.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[rearnsha at gcc dot gnu dot org]

------- Comment #27 from rearnsha at gcc dot gnu dot org  2009-11-28 15:56 -------
Created an attachment (id=19171)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19171&action=view)
Proposed patch

I think the attached should be a better patch than the one previously proposed.
 I don't have any real way to test this beyond the posted testcase, though, so
I would be grateful if you could give it a more thorough kicking.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[rearnsha at gcc dot gnu dot org]

------- Comment #26 from rearnsha at gcc dot gnu dot org  2009-11-28 14:38 -------
(In reply to comment #25)
> Further tests show that you're right about the non working kernel.

You should not use -march=iwmmxt (or -mcpu=<something equivalent>) when
building the linux kernel.  The kernel does not know how to save user-space
context for iwmmxt on entry (it only saves co-processor state on context
switches) so you will end up corrupting internal state.

It's the same situation as trying to use floating-point hardware in the kernel
-- basically, you can't, because the kernel is not set up to deal with it.

> Should the iwmmxt arch be disabled by default on GCC 4.5? At least it would
> make it clear that this arch is untested/not supported.
> 

I can't reproduce the problem on trunk with the testcase provided.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[yipiha2008 at gmail dot com]

------- Comment #25 from yipiha2008 at gmail dot com  2009-11-20 15:45 -------
Further tests show that you're right about the non working kernel.

Should the iwmmxt arch be disabled by default on GCC 4.5? At least it would
make it clear that this arch is untested/not supported.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #24 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-11-20 15:07 -------
I do not think that the non working kernel is caused by the patch, but that
there are yet more regressions for the iwmmxt arch and that this arch has never
been tested with gcc 4.4.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[yipiha2008 at gmail dot com]

------- Comment #23 from yipiha2008 at gmail dot com  2009-11-20 14:16 -------
Forget #22, as expected it does not work (kernel compiled with a patched GCC as
per #22 does not boot)


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[yipiha2008 at gmail dot com]

------- Comment #22 from yipiha2008 at gmail dot com  2009-11-19 16:47 -------
I tried applying this patch:


 (define_insn "*iwmmxt_movsi_insn"
-  [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
m,z,r,?z,Uy,z")
+  [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
m,z,rk,?z,Uy,z")
        (match_operand:SI 1 "general_operand"      "rk, I,K,mi,rk,r,z,Uy,z,
z"))]
   "TARGET_REALLY_IWMMXT
    && (   register_operand (operands[0], SImode)


I really have no clue as to whether it is correct or not.

I rely on the assembler to crash with an error in the event this generates an
invalid instruction. So far I compiled a lot of stuff with this patch applied,
and I got no ICE. However it's likely that the generated code is incorrect
somehow and my code will crash (SIGILL?) when executed. I will test this in a
few hours.

Any other idea? Maybe we could contact the people who originally wrote the
iwmmxt.md file, they might be able to help.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #21 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-11-19 14:39 -------
forget comment #20.

  WLDRW wcgr0, [fp, #-1324]

would be an invalid instruction.  Offset is 10 bit only so that the RTL is
invalid for the iwmmxt processor.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #20 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-11-19 14:09 -------
This patch creates now

---

(insn 460 148 153 20 ../sysdeps/unix/sysv/linux/libc_fatal.c:106 (set (reg:SI
43 wcgr0)
        (mem/c:SI (plus:SI (reg/f:SI 11 fp)
                (const_int -1324 [0xfffffffffffffad4])) [10 %sfp+-1292 S4
A32])) 441 {*iwmmxt_movsi_insn} (nil))
../sysdeps/unix/sysv/linux/libc_fatal.c:172: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:396

---

in glibc; which should emit the

  WLDRW wcgr0, [fp, #-1324]

instruction (??).  This instruction does not exist yet and I am not
sure about further annotations.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #19 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-11-19 13:57 -------
Created an attachment (id=19049)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19049&action=view)
patch to fix reported ICE

[not official, I really do not know whether this is the correct way]


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #18 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-11-19 13:47 -------
(define_insn "*iwmmxt_movsi_insn"
-  [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk,
m,z,r,?z,Uy,z")
+  [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk, m,z
,rk,?z,Uy,z")
-        (match_operand:SI 1 "general_operand"      "rk, I,K,mi,rk,r,z,Uy,z,
+        (match_operand:SI 1 "general_operand"      "rk, I,K,mi,rk,rk,z ,Uy,z,


will fix the reported ICE.  But, 

a) you will get other ICEs which are more tricky to fix (other _insn need new
alternatives with new assembly instructions)

b) all the 'r' constraints in other _insn should be revised whether 'k' has to
be added


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[yipiha2008 at gmail dot com]

------- Comment #17 from yipiha2008 at gmail dot com  2009-11-19 13:18 -------
I tried removing the whole movsi section from the machine definition file
(iwmmxt.md) but if I do that GCC refuses to compile. Reading the GCC internals
documentation it appears that the movsi section is mandatory.

Does anyone know which part of the movsi section of iwmmxt.md has a problem?


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[lwalkera at ieee dot org]

------- Comment #16 from lwalkera at ieee dot org  2009-11-19 00:53 -------
The bug also occurs with 4.4.2 when building uClibc:

libm/nan.c:45: error: insn does not satisfy its constraints:
(insn 95 92 49 4 libm/nan.c:42 (set (reg/f:SI 13 sp)
        (reg/f:SI 44 wcgr1 [141])) 441 {*iwmmxt_movsi_insn} (nil))
libm/nan.c:45: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

-- 

enrico dot scholz at informatik dot tu-chemnitz dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[yipiha2008 at gmail dot com]

------- Comment #15 from yipiha2008 at gmail dot com  2009-11-17 13:04 -------
Is it feasible to disable the affected instruction in the meantime, so that gcc
stops crashing? Or, if this comes from Thumb-2 support, maybe it's possible to
disable Thumb-2 support?

I'm basically looking for a workaround.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[rearnsha at gcc dot gnu dot org]

------- Comment #14 from rearnsha at gcc dot gnu dot org  2009-11-16 17:35 -------
This is probably a consequence of some changes made to support Thumb-2.   Only
a very limited number of instructions are permitted to modify SP there, and
co-processor operations are not amongst them.

I think the correct way to solve this is to add a secondary reload pattern that
handles moving co-processor regs to STACK_REGS (and vice-versa).


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[ebotcazou at gcc dot gnu dot org]

------- Comment #13 from ebotcazou at gcc dot gnu dot org  2009-11-16 17:23 -------
CCing one the of ARM maintainers.


-- 

ebotcazou at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha at gcc dot gnu dot
                   |                            |org


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[yipiha2008 at gmail dot com]

------- Comment #12 from yipiha2008 at gmail dot com  2009-11-16 16:17 -------
I would like to confirm that this bug affects gcc 4.4.2.
Compiling ffmpeg 0.5 triggers it in many places.

It may be a good idea to try to fix this in 4.5 if it's not fixed yet, before
Nov 30th which is the end of stage 3. The unassigned status of this bug makes
me wonder if it will be fixed soon enough.

Also, I don't understand why the severity of this bug is "normal" and not
"blocker", since it makes it impossible to compile some files.


-- 

yipiha2008 at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yipiha2008 at gmail dot com


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #11 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-10-30 17:49 -------
hjl: is the fix really for this PR?  Reported errors still persists after
applying it.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[hjl at gcc dot gnu dot org]

------- Comment #10 from hjl at gcc dot gnu dot org  2009-10-30 14:32 -------
Subject: Bug 40836

Author: hjl
Date: Fri Oct 30 14:32:26 2009
New Revision: 153750

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153750
Log:
Optimize -mstackrealign.

gcc/

2009-10-30  H.J. Lu  <hongjiu.lu@intel.com>

        PR target/40836
        * cfgexpand.c (expand_stack_alignment): Call update_stack_boundary
        first.  Move assert on stack_alignment_estimated just before
        setting stack_realign_needed.
        (gimple_expand_cfg): Initialize stack_alignment_estimated to 0.
        Don't call update_stack_boundary.

        * config/i386/i386.c (ix86_minimum_incoming_stack_boundary): New.
        (verride_options): Don't check ix86_force_align_arg_pointer here.
        (ix86_function_ok_for_sibcall): Use it.
        (ix86_update_stack_boundary): Likewise.

        * config/i386/i386.h (STACK_REALIGN_DEFAULT): Update comments.

gcc/testsuite/

2009-10-30  H.J. Lu  <hongjiu.lu@intel.com>

        PR target/40838
        * gcc.target/i386/incoming-6.c: New.
        * gcc.target/i386/incoming-7.c: Likewise.
        * gcc.target/i386/incoming-8.c: Likewise.
        * gcc.target/i386/incoming-9.c: Likewise.
        * gcc.target/i386/incoming-10.c: Likewise.
        * gcc.target/i386/incoming-11.c: Likewise.
        * gcc.target/i386/incoming-12.c: Likewise.
        * gcc.target/i386/incoming-13.c: Likewise.
        * gcc.target/i386/incoming-14.c: Likewise.
        * gcc.target/i386/incoming-15.c: Likewise.
        * gcc.target/i386/pr37843-4.c: Likewise.

Added:
    trunk/gcc/testsuite/gcc.target/i386/incoming-10.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-11.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-12.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-13.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-14.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-15.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-6.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-7.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-8.c
    trunk/gcc/testsuite/gcc.target/i386/incoming-9.c
    trunk/gcc/testsuite/gcc.target/i386/pr37843-4.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgexpand.c
    trunk/gcc/config/i386/i386.c
    trunk/gcc/config/i386/i386.h
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #9 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-10-23 15:13 -------
Core problem seemss to be that 4.4 differs between CORE_REGS and GENERAL_REGS
(CORE_REGS without r13/sp) and the "r", "l" + "h" constraints in the .md rules
apply to GENERAL_REGS only.   This makes some valid machine code combinations
impossible and will cause ICE hence.


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #8 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-10-23 14:31 -------
adding 'k' to the 'r' constraints seems to fix the ICE (although I did not
tested correctness of the generated code).

What is the reason that 'sp' resp. 'r13' is not catched by the 'r' & 'l'
constraints?


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #7 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-10-23 13:39 -------
When I read the RTL dumps correctly, gcc tries to assign SP to wCGR0.
This can be done by the

    tmrc  sp, wCGR0

assembly instruction which will be issued by alternative 6 in


--- iwmmxt.md ---
(define_insn "*iwmmxt_movsi_insn"
  [(set (match_operand:SI 0 "nonimmediate_operand" "=rk,r,r,rk, m,z,r,?z,Uy,z")
        (match_operand:SI 1 "general_operand"      "rk, I,K,mi,rk,r,z,Uy,z,
z"))]
   ...
   case 6: return \"tmrc\\t%0, %1\";


The corresponding constraints pair is ['r', 'z'] and it is matched by
[sp, wcgr0] afais.  What could be the reason for the ICE?


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #6 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-10-23 10:33 -------
message on file from comment #2 is now

$ ./cross/iwmmxt/bin/arm-linux-gnueabi-gcc -O2  -march=iwmmxt -mcpu=iwmmxt
-mtune=iwmmxt /tmp/foo.i

(insn 83 81 72 2
/srv/oe/projects/kk/ipan7/tmp/work/iwmmxt-linux-gnueabi/gcc-cross-4.4.1-r1.1/gcc-4.4.1/libobjc/sendmsg.c:280
(set (reg/f:SI 13 sp)
        (reg/f:SI 43 wcgr0 [147])) 441 {*iwmmxt_movsi_insn} (nil))
/srv/oe/projects/kk/ipan7/tmp/work/iwmmxt-linux-gnueabi/gcc-cross-4.4.1-r1.1/gcc-4.4.1/libobjc/sendmsg.c:283:
internal compiler error: in reload_cse_simplify_operands, at postreload.c:396

with gcc-4.4.2


-- 

enrico dot scholz at informatik dot tu-chemnitz dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.4.1                       |4.4.2


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[enrico dot scholz at informatik dot tu-chemnitz dot de]

------- Comment #5 from enrico dot scholz at informatik dot tu-chemnitz dot de  2009-10-23 10:19 -------
similar issue seen with gcc 4.4.2 (this time in glibc; can not check gcc/libobj
because glibc is required by gcc):

(insn 202 200 195 12 fxprintf.c:48 (set (reg/f:SI 13 sp)
        (reg/f:SI 44 wcgr1 [orig:193 saved_stack.38 ] [193])) 441
{*iwmmxt_movsi_insn} (nil))
fxprintf.c:56: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:396


-- 


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

[Bug target/40836] ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)

[ramana at gcc dot gnu dot org]

------- Comment #4 from ramana at gcc dot gnu dot org  2009-09-03 11:03 -------
Confirmed with rev 151319


-- 

ramana at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-09-03 11:03:01
               date|                            |


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