[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545

Tobias Burnus <burnus at gcc dot gnu.org> 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 <burnus at gcc dot gnu.org> ---
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 0x7ffff6e25e70" 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.