[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