http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29710
Dave Korn <davek at gcc dot gnu.org> 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 <davek at gcc dot gnu.org> 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)
[ . . . ]
<bb 13>:
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 <bb 15>;
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 <verify_expr.265801>, 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 <execute_function_todo.56548>, 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=<value optimized out>)
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.
