Background: GCC 4.2.0 base line + mods for UPC dialect. Problem below
is probablly a result of the UPC mods and not something
inherent in GCC 4.2.0. Although the test cases that I ran
pass at -O2, some fail when the value of THREADS (the number
of parallel threads in the application) is set to the compile
time constant one. The failing tests ICE in verify_ssa as
shown below.
I'd appreciate any tips or recommendations on how to diagnose
problems like this, likely things to look for, and so on.
The ICE occurs in tree-ssa.c at line 776 (--enable-checking is
asserted):
771
772 FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter,
773 SSA_OP_ALL_USES | SSA_OP_ALL_KILLS)
774 {
775 op = USE_FROM_PTR (use_p);
776 if (verify_use (bb, definition_block[SSA_NAME_VERSION
(op)],
777 use_p, stmt, false, !is_gimple_reg (op),
778 names_defined_in_bb))
779 goto err;
780 }
The operand, op:
(gdb) p op
$49 = 0x2aaaae1ebc60
(gdb) pt
<var_decl 0x2aaaae1ebc60 D.3609
type <record_type 0x2aaaadfa3480 upc_shared_ptr_t type_0 TI
size <integer_cst 0x2aaaadee00f0 constant invariant 128>
unit size <integer_cst 0x2aaaadee0120 constant invariant 16>
align 128 symtab 0 alias set 3
fields <field_decl 0x2aaaadfa3540 phase type <integer_type
0x2aaaadfa3780>
unsigned external bit-field nonaddressable decl_4 DI file
<built-in> line 0
size <integer_cst 0x2aaaadfa1a80 constant invariant 48>
unit size <integer_cst 0x2aaaadfa1ae0 constant invariant 6>
align 1 offset_align 128
offset <integer_cst 0x2aaaadec5750 constant invariant 0>
bit offset <integer_cst 0x2aaaadee0780 constant invariant 0>
bit_field_type <integer_type 0x2aaaaded5780 long unsigned int> context
<record_type 0x2aaaadfa3480 upc_shared_ptr_t> chain <field_decl 0x2aaaadfa3600
thread>>
chain <type_decl 0x2aaaadfa40d0 D.1420>>
used ignored TI file test02.upc line 33 size <integer_cst 0x2aaaadee00f0
128> unit size <integer_cst 0x2aaaadee0120 16>
align 128 context <function_decl 0x2aaaae1ac0e0 test02>>
and the statement, stmt:
(gdb) p stmt
$50 = 0x2aaaae1ee3c0
(gdb) pt
<modify_expr 0x2aaaae1ee3c0
type <integer_type 0x2aaaadfa3780 public unsigned DI
size <integer_cst 0x2aaaadec5db0 constant invariant 64>
unit size <integer_cst 0x2aaaadec5de0 constant invariant 8>
align 64 symtab 0 alias set -1 precision 48 min <integer_cst
0x2aaaadfa1b10 0> max <integer_cst 0x2aaaadee9000 281474976710655>>
side-effects
arg 0 <component_ref 0x2aaaae1ee370 type <integer_type 0x2aaaadfa3780>
arg 0 <var_decl 0x2aaaae1ebc60 D.3609 type <record_type 0x2aaaadfa3480
upc_shared_ptr_t>
used ignored TI file test02.upc line 33
size <integer_cst 0x2aaaadee00f0 constant invariant 128>
unit size <integer_cst 0x2aaaadee0120 constant invariant 16>
align 128 context <function_decl 0x2aaaae1ac0e0 test02>>
arg 1 <field_decl 0x2aaaadfa3540 phase type <integer_type
0x2aaaadfa3780>
unsigned external bit-field nonaddressable decl_4 DI file
<built-in> line 0
size <integer_cst 0x2aaaadfa1a80 constant invariant 48>
unit size <integer_cst 0x2aaaadfa1ae0 constant invariant 6>
align 1 offset_align 128
offset <integer_cst 0x2aaaadec5750 constant invariant 0>
bit offset <integer_cst 0x2aaaadee0780 constant invariant 0>
bit_field_type <integer_type 0x2aaaaded5780 long unsigned int> context
<record_type 0x2aaaadfa3480 upc_shared_ptr_t> chain <field_decl 0x2aaaadfa3600
thread>>>
arg 1 <integer_cst 0x2aaaadee0900 type <integer_type 0x2aaaaded5540 int>
constant invariant 0>
test02.upc:33>
The failure occurs because SSA_NAME_VERSION() in turn calls SSA_NAME_CHECK()
which checks that the tree node is an SSA_NAME node, which 'op' clearly is not.
Any ideas on how this situation might have occurred? Note that the type
of op above is the internal representation of a UPC shared pointer, which
has three fields (phase, thread, vaddr). This rep. overalays a shared
pointer value, which is generally twice the size of a conventional pointer.
Internally, UPC shared pointers are represented as POINTER_TYPE nodes whose
TREE_TYPE() is qualified by a new qualifier, "shared". Various regular
"C" optimizations on pointers have to be disabled for UPC's shared pointers.
It may be the case that with the particular settings used in the failing
test that a "c" pointer optimization was inadvertently applied to a UPC shared
pointer.
Thanks for your help.
