Compiling kdenetwork3 we get /abuild/buildsystem.f198.rguenther/usr/lib64/gcc/x86_64-suse-linux/4.1.0/cc1plus -fpreprocessed hash.3.1.ii -quiet -dumpbase hash.cpp -mtune=k8 -ansi -auxbase-strip .libs/libiris_xmpp_core_la-hash.o -O2 -O2 -Wno-long-long -Wundef -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wall -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -ansi -version -fmessage-length=0 -fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -fPIC -o hash.s hash.3.1.ii:38: error: unrecognizable insn: (insn:HI 58 57 53 0 (set (reg/f:DI 69) (plus:DI (reg/f:DI 70) (const_int 4294967233 [0xffffffc1]))) -1 (insn_list:REG_DEP_TRUE 57 (nil)) (expr_list:REG_DEAD (reg/f:DI 70) (expr_list:REG_EQUAL (const:DI (plus:DI (symbol_ref/f:DI ("*.LC0") [flags 0x2] <string_cst 0x2a95abefc0>) (const_int 4294967233 [0xffffffc1]))) (nil)))) hash.3.1.ii:38: internal compiler error: in extract_insn, at recog.c:2084 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.suse.de/feedback> for instructions.
Created attachment 10152 [details] reduced testcase testcase
Isn't this a dup of bug 20928. (I will try with a GCC after that patch to double check).
I doubt, the compiler is from Nov 4, while the patch looks like comitted at latest Oct 31. But I haven't re-checked against mainline HEAD.
Fails also with "4.1.0 20051026" and with last night's compiler.
This is another loop.c bug.
Confirmed (reduced C or C++ testcase): int* block; void final(){ unsigned int i, j; unsigned char* data = (unsigned char *)"\0"; for (i = 0; i < 8;i++) for ( ;j + 63 < 1;j += 64) block = (int*) &data[j]; }
Here is a reduced testcase without an uninitialized variable: int* block; void final(unsigned int j){ unsigned int i; unsigned char* data = (unsigned char *)"\0"; for (i = 0; i < 8;i++) for (;j + 63 < 1;j += 64) block = (int*) &data[j]; }
Honza, can you look at this? Thanks.
The reduced testcase in comment #7 fails also in 4.0.3 and 4.0.2.
And here is a testcase which fails in 3.4.5 and above: int* block; void final(unsigned int j){ int * lsm_tmp1; unsigned char * data; unsigned int i; data = (unsigned char *) ""; lsm_tmp1 = block; i = 0; do { if (j == 4294967233) { lsm_tmp1 = (int *) (data + 4294967233); j = 1; } i = i + 1; } while (i != 8); block = lsm_tmp1; }
Comment #5 is not helpful. Why is this a loop.c bug, you think? In my backtrace we bail out from regmove. It would be far more helpful if you'd add some explanation for why you think this is a loop.c bug.
Breakpoint 4, emit_move_insn (x=0x2a95a69320, y=0x2a9594c820) at expr.c:3140 3140 enum machine_mode mode = GET_MODE (x); (gdb) p debug_rtx(x) (reg:DI 68) $10 = void (gdb) p debug_rtx(y) (const:DI (plus:DI (symbol_ref/f:DI ("*.LC0") [flags 0x2] <string_cst 0x2a95a62510>) (const_int 4294967233 [0xffffffc1]))) $11 = void (gdb) bt #0 emit_move_insn (x=0x2a95a69320, y=0x2a9594c820) at expr.c:3140 #1 0x0000000000a6e5a9 in move_movables (loop=0xe72f80, movables=0xe766d8, threshold=93, insn_count=9) at loop.c:2365 #2 0x0000000000a6c59a in scan_loop (loop=0xe72f80, flags=0) at loop.c:1522 #3 0x0000000000a6a1a1 in loop_optimize (f=0x2a9589b940, dumpfile=0x0, flags=0) at loop.c:909 #4 0x0000000000a81e30 in rest_of_handle_loop_optimize () at loop.c:11784 #5 0x0000000000946f77 in execute_one_pass (pass=0xd9ae80) at passes.c:827 A bit further down: 3185 last_insn = emit_move_insn_1 (x, y); (gdb) disab 4 (gdb) next 3187 if (y_cst && REG_P (x) (gdb) p debug_rtx(last_insn) (insn 60 59 0 (set (reg:DI 68) (plus:DI (reg/f:DI 69) (const_int 4294967233 [0xffffffc1]))) -1 (nil) (nil)) $12 = void (gdb) p recog_memoized (last_insn) $13 = -1 (gdb) next 3191 set_unique_reg_note (last_insn, REG_EQUAL, y_cst); (gdb) 3193 return last_insn; (gdb) 3194 } So there's your wrong instruction, produced by emit_move_insn itself... :-(
ICE on a primary platform, in a popular package.
(In reply to comment #13) > ICE on a primary platform, in a popular package. As I mentioned in another bug, I think Mark should be the only one which changes the Priority.
(In reply to comment #14) > (In reply to comment #13) > > ICE on a primary platform, in a popular package. > As I mentioned in another bug, I think Mark should be the only one which > changes the Priority. I should note that Mark agreed with me (though it was via a private email).
And here is one which also fails in 3.3.6: int final(int j){ unsigned int i = 0; do { if (j) j = (__SIZE_TYPE__)&""[4294967233]; i = i + 1; } while (i != 8); return j; }
(In reply to comment #16) > And here is one which also fails in 3.3.6: Hmm but passes in 4.0.3.
Note that the original problem, ICE in kdenetwork3 only happens with mainline.
Created attachment 10160 [details] Patch I'm testing this patch.
By the way, Richard, I just want to note that while this is obviously a compiler bug, it is only being triggered for the original test case because of the uninitialized variable i in sha1_update: void sha1_update(SHA1_CONTEXT* context, unsigned char* data, Q_UINT32 len) { Q_UINT32 i, j; if((j + len) > 63) { for ( ; i + 63 < len; i += 64) { transform(context->state, &data[i]); } } } I don't know if that was a consequence of your test case reduction or not.
its an error in the testcase, the original code initializes i: if((j + len) > 63) { 562 memcpy(&context->buffer[j], data, (i = 64-j)); 563 transform(context->state, context->buffer); 564 for ( ; i + 63 < len; i += 64) { 565 transform(context->state, &data[i]); 566 }
Subject: Bug 24683 Author: ian Date: Mon Nov 7 18:52:24 2005 New Revision: 106601 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106601 Log: ./: PR rtl-optimization/24683 * config/i386/i386.c (legitimize_pic_address): If constant operand to PLUS is too large, put it in a register. testsuite/: PR rtl-optimization/24683 * gcc.dg/pr24683.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr24683.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
Subject: Bug 24683 Author: ian Date: Mon Nov 7 18:55:03 2005 New Revision: 106602 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106602 Log: ./: PR rtl-optimization/24683 * config/i386/i386.c (legitimize_pic_address): If constant operand to PLUS is too large, put it in a register. testsuite/: PR rtl-optimization/24683 * gcc.dg/pr24683.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr24683.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/i386/i386.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog
Fixed on 4.0 branch and on mainline. The 3.4 branch breaks in a slightly different way. I'm not going to worry about it since you can only create this problem by building implausible addresses that include offsets of more than 2GB.