[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717
--- Comment #7 from Jakub Jelinek ---
As A.3 is in the body of a construct that is outlined into a separate function,
it should be moved to the *omp_fn* function with it.
If you look at simple
int
main ()
{
#pragma omp parallel
{
int a = 25;
++a;
}
}
you can see in the gimple dump two pairs of {}s instead of just once:
#pragma omp parallel
{
{
int a;
a = 25;
a = a + 1;
}
}
(ditto target, task, (host) teams etc.), while with acc parallel that isn't the
case:
#pragma omp target oacc_parallel map(from:(*array.12_5) [len: D.4276])
map(alloc:array [pointer assign, bias: 0]) firstprivate(ubound.0)
firstprivate(nn)
{
The reason for that for the OpenMP construct is exactly to ensure that
move_sese_region_to_fn does the right thing with it.
[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 --- Comment #6 from Tom de Vries --- (In reply to Tom de Vries from comment #5) > However, somehow the A.3 remains part of the BLOCK_VARS of foo, so when ipa > inline (activated by pta-ipa, which does node->get_body ()) inlines foo into > main, it does a remap of block-var A.3, and then a remap of its value-expr > A.14, and then a remap of its TREE_TYPE. Which has the effect of changing > the TREE_TYPE of A.14 in foo.0._omp_fn.0. Thomas, Jakub, any idea what the expected behaviour is here? Should A.3 be a part of the BLOCK_VARS of foo, or not?
[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 --- Comment #5 from Tom de Vries --- At original: ... void foo () ... #pragma acc parallel ... integer(kind=4) A.3[0:D.4266]; ... At gimple: ... void foo () ... #pragma omp target oacc_parallel ... integer(kind=4)[0:D.4266] * A.14; integer(kind=4) A.3[0:D.4266] [value-expr: *A.14]; ... A.14 = __builtin_alloca_with_align (D.4329, 32); ... And at ompexp: ... void foo.0._omp_fn.0 () ... integer(kind=4) A.3[0:D.4266] [value-expr: *A.14]; integer(kind=4)[0:D.4266] * A.14; ... A.14 = __builtin_alloca_with_align (D.4392, 32); ... and: ... void foo () ... __builtin_GOACC_parallel_keyed (-1, foo.0._omp_fn.0, 4, &.omp_data_arr.20, &.omp_data_sizes.21, &.omp_data_kinds.22, 0); ... However, somehow the A.3 remains part of the BLOCK_VARS of foo, so when ipa inline (activated by pta-ipa, which does node->get_body ()) inlines foo into main, it does a remap of block-var A.3, and then a remap of its value-expr A.14, and then a remap of its TREE_TYPE. Which has the effect of changing the TREE_TYPE of A.14 in foo.0._omp_fn.0.
[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 --- Comment #4 from Tom de Vries --- (In reply to Tom de Vries from comment #3) > The mismatch seems to be: > ... > (gdb) call debug_generic_expr (name.typed.type) > integer(kind=4)[0:D.4266] * > (gdb) call debug_generic_expr (name.ssa_name.var.typed.type) > integer(kind=4)[0:D.4433] * > ... Setting a breakpoint at: ... Breakpoint 4, ipa_pta_execute () at /home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-structalias.cc:8322 8322 gcc_assert (!node->clone_of); ... and doing: ... (gdb) watch -l node->decl.function_decl.f.gimple_df->ssa_names.m_vecdata[21].ssa_name.var.typed.type ... the second time we hit the breakpoint for foo.0._omp_fn.0, I hit the moment that the type changes: ... (gdb) c Continuing. Hardware watchpoint 5: -location node->decl.function_decl.f.gimple_df->ssa_names.m_vecdata[21].ssa_name.var.typed.type Old value = (tree_node *) 0x7673abd0 New value = (tree_node *) 0x7635d9d8 ... with: ... (gdb) call debug_generic_expr ((tree_node *) 0x7673abd0) integer(kind=4)[0:D.4266] * (gdb) call debug_generic_expr ((tree_node *) 0x7635d9d8) integer(kind=4)[0:D.4433] * ... Backtrace: ... (gdb) bt #0 copy_tree_body_r (tp=0x7634e3d8, walk_subtrees=0x7fffd04c, data=0x7fffd390) at /home/vries/oacc/trunk/source-gcc/gcc/tree-inline.cc:1418 #1 0x011d4664 in walk_tree_1 (tp=0x7634e3d8, tp@entry=0x7fffd098, func=func@entry=0xf18070 , data=data@entry=0x7fffd390, pset=pset@entry=0x0, lh=lh@entry=0x0) at /home/vries/oacc/trunk/source-gcc/gcc/tree.cc:11070 #2 0x00f13ac4 in remap_decls (decls=, nonlocalized_list=nonlocalized_list@entry=0x76342688, id=id@entry=0x7fffd390) at /home/vries/oacc/trunk/source-gcc/gcc/tree-inline.cc:791 #3 0x00f15f10 in remap_block (block=block@entry=0x7fffd128, id=id@entry=0x7fffd390) at /home/vries/oacc/trunk/source-gcc/gcc/tree-inline.cc:822 #4 0x00f16096 in remap_blocks (block=block@entry=0x76342060, id=id@entry=0x7fffd390) at /home/vries/oacc/trunk/source-gcc/gcc/tree-inline.cc:841 #5 0x00f160c3 in remap_blocks (block=, id=id@entry=0x7fffd390) at /home/vries/oacc/trunk/source-gcc/gcc/tree-inline.cc:844 #6 0x00f21622 in expand_call_inline (bb=, bb@entry=0x76358a28, stmt=0x7635b990, id=id@entry=0x7fffd390, to_purge=to_purge@entry=0x7fffd370) at /home/vries/oacc/trunk/source-gcc/gcc/tree-inline.cc:5033 #7 0x00f22aea in gimple_expand_calls_inline (to_purge=0x7fffd370, id=0x7fffd390, bb=0x76358a28) at /home/vries/oacc/trunk/source-gcc/gcc/tree-inline.cc:5320 --Type for more, q to quit, c to continue without paging-- #8 optimize_inline_calls (fn=0x7673b100) at /home/vries/oacc/trunk/source-gcc/gcc/tree-inline.cc:5492 #9 0x00beaa7c in inline_transform (node=) at /home/vries/oacc/trunk/source-gcc/gcc/ipa-inline-transform.cc:790 #10 0x00d7f761 in execute_one_ipa_transform_pass (do_not_collect=true, ipa_pass=0x2f52700, node=0x76343330) at /home/vries/oacc/trunk/source-gcc/gcc/passes.cc:2335 #11 execute_all_ipa_transforms (do_not_collect=do_not_collect@entry=true) at /home/vries/oacc/trunk/source-gcc/gcc/passes.cc:2398 #12 0x0094f301 in cgraph_node::get_body (this=this@entry=0x76343330) at /home/vries/oacc/trunk/source-gcc/gcc/cgraph.cc:4044 #13 0x010ed712 in ipa_pta_execute () at /home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-structalias.cc:8320 #14 (anonymous namespace)::pass_ipa_pta::execute (this=) at /home/vries/oacc/trunk/source-gcc/gcc/tree-ssa-structalias.cc:8744 #15 0x00d7fb91 in execute_one_pass (pass=pass@entry=0x2f52b90) at /home/vries/oacc/trunk/source-gcc/gcc/passes.cc:2643 #16 0x00d816b2 in execute_ipa_pass_list (pass=0x2f52b90) at /home/vries/oacc/trunk/source-gcc/gcc/passes.cc:3083 #17 0x0095e0cb in symbol_table::compile (this=this@entry=0x76547000) at /home/vries/oacc/trunk/source-gcc/gcc/cgraphunit.cc:2311 --Type for more, q to quit, c to continue without paging-- #18 0x00962130 in symbol_table::compile (this=0x76547000) at /home/vries/oacc/trunk/source-gcc/gcc/cgraphunit.cc:2532 #19 symbol_table::finalize_compilation_unit (this=0x76547000) at /home/vries/oacc/trunk/source-gcc/gcc/cgraphunit.cc:2529 #20 0x00e7b44e in compile_file () at /home/vries/oacc/trunk/source-gcc/gcc/toplev.cc:479 #21 0x006fcd1f in do_compile (no_backend=false) at /home/vries/oacc/trunk/source-gcc/gcc/toplev.cc:2168 #22 toplev::main (this=this@entry=0x7fffd86e, argc=, argc@entry=18, argv=, argv@entry=0x7fffd978) at /home/vries/oacc/trunk/source-gcc/gcc/toplev.cc:2320 #23 0x006ff20b in main (argc=18, argv=0x7fffd978) at /home/vries/oacc/trunk/source-gcc/gcc/main.cc:39 ... I guess we're seeing the effect of: ... if (TREE_CODE
[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717
--- Comment #3 from Tom de Vries ---
The test that is failing, is:
...
760 if (SSA_NAME_VAR (ssa_name) != NULL_TREE
761 && TREE_TYPE (ssa_name) != TREE_TYPE (SSA_NAME_VAR (ssa_name)))
762 {
763 error ("type mismatch between an SSA_NAME and its symbol");
764 return true;
765 }
...
For ssa-name:
...
(gdb) call debug_generic_expr (name)
A.14_21
(gdb) call debug_tree (name)
sizes-gimplified BLK size
unit-size
align:32 warn_if_not_align:0 symtab:0 alias-set -1
structural-equality domain
pointer_to_this >
public unsigned DI
size
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 structural-equality>
var
def_stmt A.14_21 = __builtin_alloca_with_align (_19, 32);
version:21
ptr-info 0x763459f0>
...
The mismatch seems to be:
...
(gdb) call debug_generic_expr (name.typed.type)
integer(kind=4)[0:D.4266] *
(gdb) call debug_generic_expr (name.ssa_name.var.typed.type)
integer(kind=4)[0:D.4433] *
...
[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 --- Comment #2 from Thomas Schwinge --- Reproduced, thanks for the report. The problem disappears when adding '-fno-ipa-pta' to '-O1 -fopenacc -fstack-arrays'. Not yet analyzed the differences. The problem does not reproduce with '-O1 -fopenmp -fipa-pta -fstack-arrays' and code changes as per: -!$acc parallel copyout(array) +!$omp target map(from:array) array = [(-i, i = 1, nn)] -!$acc end parallel +!$omp end target ..., so really points to something specific to OpenACC handling.
[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org, ||vries at gcc dot gnu.org Target Milestone|--- |9.5 Keywords||openacc Ever confirmed|0 |1 Summary|ICE: verify_ssa failed |[9/10/11/12 Regression] |(Error: type mismatch |ICE: verify_ssa failed |between an SSA_NAME and its |(Error: type mismatch |symbol) |between an SSA_NAME and its ||symbol) Last reconfirmed||2022-02-28 Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- Started with r6-5810-g597a8ab9c6f57c416c2b0a734c2098fa0335e628 As -fopenacc has been introduced already in r5-6458-g41dbbb3789850dfea98dd8984f69806284f87b6e , I think this means it is a regression from GCC 5.x.
