On 11/4/19 6:35 AM, Richard Biener wrote: > On Mon, Nov 4, 2019 at 10:09 AM Martin Liška <mli...@suse.cz> wrote: >> >> On 11/1/19 10:51 PM, Jeff Law wrote: >>> On 10/31/19 10:01 AM, Martin Liška wrote: >>>> Hi. >>>> >>>> operand_equal_p can properly handle situation where we have a CONSTRUCTOR >>>> where indices are NULL: >>>> >>>> if (!operand_equal_p (c0->value, c1->value, flags) >>>> /* In GIMPLE the indexes can be either NULL or matching i. >>>> Double check this so we won't get false >>>> positives for GENERIC. */ >>>> || (c0->index >>>> && (TREE_CODE (c0->index) != INTEGER_CST >>>> || compare_tree_int (c0->index, i))) >>>> || (c1->index >>>> && (TREE_CODE (c1->index) != INTEGER_CST >>>> || compare_tree_int (c1->index, i)))) >>>> return false; >>>> >>>> but the corresponding hash function always hashes field (which >>>> can be NULL_TREE or equal to ctor index). >>>> >>>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. >>>> >>>> Ready to be installed? >>>> Thanks, >>>> Martin >>>> >>>> gcc/ChangeLog: >>>> >>>> 2019-10-31 Martin Liska <mli...@suse.cz> >>>> >>>> PR ipa/92304 >>>> * fold-const.c (operand_compare::hash_operand): Fix field >>>> hashing of CONSTRUCTOR. >>> OK. One question though, do these routines need to handle >>> CONSTRUCTOR_NO_CLEARING? >> >> Good point, but I bet it's just a flag used in GENERIC, right? > > Yes. It matters for gimplification only. I don't think we can > optimistically make use of it in operand_equal_p. I'm not thinking about optimistically using it, quite the opposite :-)
My worry is that we could potentially consider two CONSTRUCTOR nodes equal in the hashing and equality functions when they really aren't equal due to the semantics around CONSTRUCTOR_NO_CLEARING. jeff
