------- 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);
do
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.
Richard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
