[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Tobias Burnus --- FIXED on mainline (GCC 13). Thanks for this any many other reports!
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 --- Comment #6 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:3843dc1460259fbca1f336b0259f0b6b527d77ae commit r13-6394-g3843dc1460259fbca1f336b0259f0b6b527d77ae Author: Tobias Burnus Date: Wed Mar 1 15:11:53 2023 +0100 OpenMP: Ignore side-effects when finding struct comps [PR108545] With volatile, two 'x.data' comp refs aren't regarded as identical, causing that the two items in the first map of map(to:x.a, x.a.data) map(pset: x.a.data) end up in separate 'map(struct:x)', which will cause a later ICE. Solution: Ignore side effects when checking the operands in the hash for being equal. (Do so by creating a variant of tree_operand_hash that calls operand_equal_p with OEP_MATCH_SIDE_EFFECTS.) gcc/ChangeLog: PR middle-end/108545 * gimplify.cc (struct tree_operand_hash_no_se): New. (omp_index_mapping_groups_1, omp_index_mapping_groups, omp_reindex_mapping_groups, omp_mapped_by_containing_struct, omp_tsort_mapping_groups_1, omp_tsort_mapping_groups, oacc_resolve_clause_dependencies, omp_build_struct_sibling_lists, gimplify_scan_omp_clauses): Use tree_operand_hash_no_se instead of tree_operand_hash. gcc/testsuite/ChangeLog: PR middle-end/108545 * c-c++-common/gomp/map-8.c: New test. * gfortran.dg/gomp/map-9.f90: New test.
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 Tobias Burnus changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus --- Created attachment 54554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54554&action=edit Draft patch - adds and uses tree_operand_sideeff_hash The patch does what I wrote last: Adds The problem (for the Fortran testcase but probably for both) occurs for omp_mapped_by_containing_struct's omp_mapping_group **wholestruct = grpmap->get (wsdecl); where 'wsdecl' is 'x.a'. If I look at operand_equal_p – invoked by 'tree_operand_hash::equal, I get 'true' without 'volatile' and 'false' with. The only difference is "side-effects volatile" for the component_ref and that "component_ref 0x76e25e70" are not identical but different tree; the arguments etc. are identical. In operand_compare::operand_equal_p there is: if (arg0 == arg1 && ! (flags & OEP_ONLY_CONST) && (TREE_CODE (arg0) == SAVE_EXPR || (flags & OEP_MATCH_SIDE_EFFECTS) || (! TREE_SIDE_EFFECTS (arg0) && ! TREE_SIDE_EFFECTS (arg1 return true; Thus, it seems as if we need a variant of gcc/tree-hash-traits.h that passes not 0 but OEP_MATCH_SIDE_EFFECTS as flag to operand_equal_p.
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 --- Comment #4 from Tobias Burnus --- For the C/C++ testcase of comment 3, bisecting points to commit r12-5835-g0ab29cf0bb68960c1f87405f14b4fb2109254e2f "openmp: Improve OpenMP target support for C++ (PR92120)"
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 --- Comment #3 from Tobias Burnus --- Fortran: Same issue (ICE) also with: !$omp target enter data map(to: x) Crucial is the VOLATILE attribute. * * * The following C code already gives an ICE with GCC 12, it works with GCC 11. (Either of the two lines fail. I think that's invalid OpenMP code, but I do not have a real overview about 'map' - and I fear no one has.) volatile struct t { struct t2 { int *a; int c; } u; int b; } my_struct; volatile struct t3 { int *a; int c; } my_struct3; void f() { #pragma omp target enter data map(to:my_struct.u) map(to:my_struct.u.a) #pragma omp target enter data map(to:my_struct3) map(to:my_struct3.a) }
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus --- !$omp target enter data map(to: x%a) The original tree has the expected: #pragma omp target enter data map(to:x.a [len: 64]) map(to:*(integer(kind=4)[0:] *) x.a.data [len: D.4282 * 4]) map(always_pointer:(integer(kind=4)[0:] *) x.a.data [pointer assign, bias: 0]) The gimple dump adds a single 'struct': #pragma omp target enter data map(struct:x [len: 1]) map(to:x.a [len: 64]) map(struct:x [len: 1]) map(alloc:x.a.data [len: 8]) map(to:MEM [(integer(kind=4)[0:] *)_6] [len: _5]) map(always_pointer:x.a.data [pointer assign, bias: 0]) The nonindented lines are new in GCC 13 (mainline) compared to GCC 12 and obviously wrong. * * * Observations: * OG12 is not affected but it also does not have the commit r13-2665-g23baa717c991d77f206a9358ce2c04960ccf9eea "struct sibling list gimplification extension and rework" * Except for an added 'always', the dump does not change with my pending patch https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612678.html "Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings"
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|fortran |middle-end