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. Richard. > Martin > > > > > jeff > > >
