------- Comment #14 from rguenther at suse dot de  2010-09-03 09:06 -------
Subject: Re:  -fcompare-debug failure at -O3

On Fri, 3 Sep 2010, aoliva at gcc dot gnu dot org wrote:

> ------- Comment #13 from aoliva at gcc dot gnu dot org  2010-09-03 08:59 
> -------
> The different types arise when, say, we copyprop a const-unqualified variable
> into a MEM_REF that used to reference a const-qualified temp.  The top-level
> const qualifications are irrelevant at that point, for we're dealing with
> rvalues of pointer types.  I'm experimenting with simply dropping the
> TYPE_QUALS test from tree-pretty-print.  This fixed the pt.c -fcompare-debug
> problem.  Richard, is there any reason for top-level qualifiers to be relevant
> in MEM_REF operands?

Hmm, not really.  But in the end at some point I want to drop the
fancy printing of MEM_REFs.

What you can do is instead of

            dump_generic_node (buffer, TREE_TYPE (TREE_OPERAND (node, 1)),
                               spc, flags | TDF_SLIM, false);


            dump_generic_node (buffer, TYPE_MAIN_VARIANT (TREE_TYPE 
(TREE_OPERAND (node, 1))),
                               spc, flags | TDF_SLIM, false);

as that is what matters.  Or even better, see if the issue goes away
when you change the gimplifier to use the main variant in the first
place.  That's sth I would prefer - not sure why I missed that.




Reply via email to