[PATCH] Fix hash_operand for fields of a CONSTRUCTOR.
Richard Biener
richard.guenther@gmail.com
Mon Nov 4 13:36:00 GMT 2019
On Mon, Nov 4, 2019 at 10:09 AM Martin Liška <mliska@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 <mliska@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
> >
>
More information about the Gcc-patches
mailing list