Bug 40836 - ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
Summary: ICE: "insn does not satisfy its constraints" (iwmmxt_movsi_insn)
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 4.4.2
: P3 blocker
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
Depends on:
Blocks:
 
Reported: 2009-07-23 09:45 UTC by enrico.scholz
Modified: 2017-08-03 08:21 UTC (History)
6 users (show)

See Also:
Host: x86_64-linux
Target: arm-linux-gnueabi
Build: x86_64-linux
Known to work:
Known to fail:
Last reconfirmed: 2009-09-03 11:03:01


Attachments
gcc cmdline + output (1.76 KB, text/plain)
2009-07-23 09:46 UTC, enrico.scholz
Details
preprocessor output (20.72 KB, text/plain)
2009-07-23 09:47 UTC, enrico.scholz
Details
assembly output (3.45 KB, text/plain)
2009-07-23 09:48 UTC, enrico.scholz
Details
patch to fix reported ICE (650 bytes, patch)
2009-11-19 13:57 UTC, enrico.scholz
Details | Diff
Proposed patch (301 bytes, patch)
2009-11-28 15:56 UTC, Richard Earnshaw
Details | Diff
arm-linux-gnueabi-gcc -march=iwmmxt -mcpu=iwmmxt -mtune=iwmmxt -std=gnu99 -c -O2 libc_fatal.i (35.15 KB, text/plain)
2009-11-28 23:08 UTC, enrico.scholz
Details
preprocessed source that crashes (46.91 KB, text/plain)
2012-09-11 19:11 UTC, Daniel Drake
Details

Note You need to log in before you can comment on or make changes to this bug.
Description enrico.scholz 2009-07-23 09:45:13 UTC
When trying to build an iwmmxt optimized gcc 4.4.1, build fails in libobjc with an ICE:

  In function 'objc_msg_sendv':
  error: insn does not satisfy its constraints:
  (set (reg/f:SI 13 sp)
          (reg/f:SI 43 wcgr0 [146])) 441 {*iwmmxt_movsi_insn} (nil))
  internal compiler error: in reload_cse_simplify_operands, at postreload.c:396
  Please submit a full bug report,
Comment 1 enrico.scholz 2009-07-23 09:46:30 UTC
Created attachment 18242 [details]
gcc cmdline + output
Comment 2 enrico.scholz 2009-07-23 09:47:54 UTC
Created attachment 18243 [details]
preprocessor output
Comment 3 enrico.scholz 2009-07-23 09:48:25 UTC
Created attachment 18244 [details]
assembly output
Comment 4 Ramana Radhakrishnan 2009-09-03 11:03:01 UTC
Confirmed with rev 151319
Comment 5 enrico.scholz 2009-10-23 10:19:21 UTC
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
Comment 6 enrico.scholz 2009-10-23 10:33:42 UTC
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
Comment 7 enrico.scholz 2009-10-23 13:39:27 UTC
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?
Comment 8 enrico.scholz 2009-10-23 14:31:43 UTC
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?
Comment 9 enrico.scholz 2009-10-23 15:13:27 UTC
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.
Comment 10 hjl@gcc.gnu.org 2009-10-30 14:32:44 UTC
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

Comment 11 enrico.scholz 2009-10-30 17:49:11 UTC
hjl: is the fix really for this PR?  Reported errors still persists after applying it.
Comment 12 yipiha2008 2009-11-16 16:17:45 UTC
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.
Comment 13 Eric Botcazou 2009-11-16 17:23:02 UTC
CCing one the of ARM maintainers.
Comment 14 Richard Earnshaw 2009-11-16 17:35:13 UTC
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).
Comment 15 yipiha2008 2009-11-17 13:04:12 UTC
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.
Comment 16 Laine Walker-Avina 2009-11-19 00:53:29 UTC
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
Comment 17 yipiha2008 2009-11-19 13:18:16 UTC
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?
Comment 18 enrico.scholz 2009-11-19 13:47:56 UTC
(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
Comment 19 enrico.scholz 2009-11-19 13:57:27 UTC
Created attachment 19049 [details]
patch to fix reported ICE

[not official, I really do not know whether this is the correct way]
Comment 20 enrico.scholz 2009-11-19 14:09:03 UTC
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.
Comment 21 enrico.scholz 2009-11-19 14:39:02 UTC
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.
Comment 22 yipiha2008 2009-11-19 16:47:03 UTC
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.
Comment 23 yipiha2008 2009-11-20 14:16:41 UTC
Forget #22, as expected it does not work (kernel compiled with a patched GCC as per #22 does not boot)
Comment 24 enrico.scholz 2009-11-20 15:07:23 UTC
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.
Comment 25 yipiha2008 2009-11-20 15:45:24 UTC
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.
Comment 26 Richard Earnshaw 2009-11-28 14:38:15 UTC
(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.
Comment 27 Richard Earnshaw 2009-11-28 15:56:53 UTC
Created attachment 19171 [details]
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.
Comment 28 enrico.scholz 2009-11-28 23:08:10 UTC
Created attachment 19173 [details]
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.
Comment 29 Ian Bolton 2010-07-09 17:02:56 UTC
(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.
Comment 30 Daniel Drake 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.
Comment 31 Daniel Drake 2012-09-11 19:11:27 UTC
Created attachment 28173 [details]
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.
Comment 32 Daniel Drake 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.
Comment 33 Jackie Rosen 2014-02-16 13:14:27 UTC Comment hidden (spam)
Comment 34 Ramana Radhakrishnan 2015-06-24 23:37:26 UTC
I guess waiting till someone tests on iwmmxt2 or proposes an actual tested patch for this on trunk.
Comment 35 Eric Gallager 2017-08-03 03:56:49 UTC
(In reply to Ramana Radhakrishnan from comment #34)
> I guess waiting till someone tests on iwmmxt2 or proposes an actual tested
> patch for this on trunk.

No one's done that in the last 2 years. Does it really make sense for this to be a "blocker" when gcc's had multiple releases in the last few years that this bug hasn't blocked?
Comment 36 Richard Earnshaw 2017-08-03 08:21:59 UTC
No feedback in over a year, closing.