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,
Created attachment 18242 [details] gcc cmdline + output
Created attachment 18243 [details] preprocessor output
Created attachment 18244 [details] assembly output
Confirmed with rev 151319
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
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
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?
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?
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.
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
hjl: is the fix really for this PR? Reported errors still persists after applying it.
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.
CCing one the of ARM maintainers.
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).
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.
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
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?
(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
Created attachment 19049 [details] patch to fix reported ICE [not official, I really do not know whether this is the correct way]
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.
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.
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.
Forget #22, as expected it does not work (kernel compiled with a patched GCC as per #22 does not boot)
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.
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.
(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.
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.
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.
(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.
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.
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.
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 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.
I guess waiting till someone tests on iwmmxt2 or proposes an actual tested patch for this on trunk.
(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?
No feedback in over a year, closing.