From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10311 invoked by alias); 11 Dec 2010 10:17:46 -0000 Received: (qmail 10303 invoked by uid 22791); 11 Dec 2010 10:17:45 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_TM X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 11 Dec 2010 10:17:39 +0000 From: "davek at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/29710] gnat ICEs on -fprefetch-loop-arrays -O1. X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: davek at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Last reconfirmed CC Version Known to fail Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Sat, 11 Dec 2010 10:17:00 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-12/txt/msg01178.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29710 Dave Korn changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|2006-11-10 19:32:46 |2010-12-11 19:32:46 CC| |davek at gcc dot gnu.org Version|4.2.0 |4.6.0 Known to fail| |4.6.0 --- Comment #6 from Dave Korn 2010-12-11 10:17:11 UTC --- I've run into what appears to be the same problem with 4.6.0 HEAD in java: http://gcc.gnu.org/ml/gcc/2010-12/msg00308.html http://gcc.gnu.org/ml/gcc/2010-12/msg00315.html > FAIL: newarray_overflow -O3 compilation from source > FAIL: newarray_overflow -O3 -findirect-dispatch compilation from source The problem showed up as a crash during gimple stmt verification. Turning on tree dumps moved the crash earlier, to a point where it was trying to dump a call to builtin_prefetch during the 118t.aprefetch pass. The GIMPLE context in that file, after working around the dump problem, shows: ;; Function newarray_overflow.int_check() (_ZN17newarray_overflow9int_checkEJvv) [ . . . ] : D.1283_116 = &MEM[(int *)#ref#2#2_6].data[#slot#3#12.29_44]{lb: 0 sz: 4}; D.1284_85 = D.1283_116 + 1275068416; newarray_overflow.int_check.__builtin_prefetch (D.1284_85, 0, ); #slot#2#0_53 = MEM[(int *)#ref#2#2_6].data[#slot#3#12.29_44]{lb: 0 sz: 4}; goto ; Judging by the way all the RTL dump files (and the generated assembler source) leave off immediately before this function, it's some kind of invalid GIMPLE problem. The verification failure occurred here: > (gdb) bt > #0 walk_gimple_op (stmt=0x7fe106e0, > callback_op=0x4a0ef0 , wi=0x326c554) > at /gnu/gcc/gcc/gcc/gimple.c:1342 > #1 0x0054a0fd in verify_stmts () at /gnu/gcc/gcc/gcc/tree-cfg.c:4156 > #2 0x0054a94a in verify_ssa (check_modified_stmt=1 '\001') > at /gnu/gcc/gcc/gcc/tree-ssa.c:878 > #3 0x008cc671 in execute_function_todo.56548 (data=0x1) > at /gnu/gcc/gcc/gcc/passes.c:1237 > #4 0x00776449 in do_per_function ( > callback=0x8cc530 , data=0x1) > at /gnu/gcc/gcc/gcc/passes.c:1084 > #5 0x00540e90 in execute_todo (flags=1) at /gnu/gcc/gcc/gcc/passes.c:1268 > #6 0x00541140 in execute_one_pass (pass=0xaf1320) > at /gnu/gcc/gcc/gcc/passes.c:1576 ... verifying a gimple call statement: > (gdb) p stmt[0].gimple_call > $8 = {membase = {opbase = {gsbase = {code = TS_IDENTIFIER, no_warning = 0, > visited = 0, nontemporal_move = 0, plf = 0, modified = 0, > has_volatile_ops = 0, pad = 0, subcode = 0, uid = 0, location = 0, > num_ops = 6, bb = 0x7fda3210, block = 0x0}, def_ops = 0x0, > use_ops = 0x7fed6f30}, vdef = 0x0, vuse = 0x0}, call_used = { > anything = 1, nonlocal = 0, escaped = 0, ipa_escaped = 0, null = 0, > vars_contains_global = 0, vars_contains_restrict = 0, vars = 0x0}, > call_clobbered = {anything = 0, nonlocal = 0, escaped = 0, ipa_escaped = 0, > null = 0, vars_contains_global = 0, vars_contains_restrict = 0, > vars = 0x0}, op = {0x0}} By forcing the num_ops down to 5, I managed to defer the crash until expand_builtin_prefetch: Program received signal SIGSEGV, Segmentation fault. expand_builtin_prefetch (exp=) at /gnu/gcc/gcc/gcc/builtins.c:1131 1131 if (TREE_CODE (arg2) != INTEGER_CST) So that made me suspect the third argument to the call was invalid, and breakpointing on gimple_build_call showed the problem: (gdb) bt #0 gimple_build_call (fn=0x7ff8f580, nargs=3) at /gnu/gcc/gcc/gcc/gimple.c:261 #1 0x008c310d in tree_ssa_loop_prefetch () at /gnu/gcc/gcc/gcc/tree-ssa-loop-pr efetch.c:1121 (gdb) x/8xw $esp 0x326c5fc: 0x008c310d 0x7ff8f580 0x00000003 0x7feb8280 0x326c60c: 0x7fef03d8 0x00000000 0x00000000 0x00080000 fn and nargs can be seen in the middle of the first row there, and the next three words should be the arguments to the gimple call, but you can see the third one is null. That comes from this line in issue_prefetch_ref() in tree-ssa-loop-prefetch.c: prefetch = gimple_build_call (built_in_decls[BUILT_IN_PREFETCH], 3, addr, write_p, local); and the variable local is set like so: local = nontemporal ? integer_zero_node : integer_three_node; Sure enough, on investigating the integer_xxx_nodes, TI_INTEGER_ZERO, // = 13 TI_INTEGER_ONE, // = 14 TI_INTEGER_THREE, // = 15 TI_INTEGER_MINUS_ONE, // = 16 (gdb) p global_trees[13] $20 = (union tree_node *) 0x7fef03d8 (gdb) p global_trees[14] $21 = (union tree_node *) 0x7fef03f0 (gdb) p global_trees[15] $22 = (union tree_node *) 0x0 (gdb) p global_trees[16] $23 = (union tree_node *) 0x7fef0438 ... it appears that integer_three_node has not been initialised. Looks to me like that might be something that was added after the others and maybe only the c family compilers got updated to set it up in their init routines; I'll take a closer look. Although I haven't verified that this is the same as the original problem report, it really looks like it, modulo various changes to the compiler's internals since 4.2; in particular, (In reply to comment #4) > (gdb) p current_stmt_group > $6 = (struct stmt_group *) 0x0 ... that looks like that null third argument causing problems to me.