This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix dump scan in test devirt-40.C
- From: Martin Jambor <mjambor at suse dot cz>
- To: GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 4 Nov 2014 16:57:31 +0100
- Subject: Re: [PATCH] Fix dump scan in test devirt-40.C
- Authentication-results: sourceware.org; auth=none
- References: <20141104153706 dot GF3173 at virgil dot suse> <CAFiYyc3o0SzCuUP33+ZrFfweQ_iLmjbf=w_sJxAnKjWzMuN8aw at mail dot gmail dot com>
On Tue, Nov 04, 2014 at 04:47:18PM +0100, Richard Biener wrote:
> On Tue, Nov 4, 2014 at 4:37 PM, Martin Jambor <mjambor@suse.cz> wrote:
> > Hi,
> >
> > since revision 216728, testsuite/g++.dg/ipa/devirt-40.C is failing
> > because although the tested-for devirtualization does happen, it is
> > probably being done earlier and the string we are trying to match is
> > not emitted. But the important thing is that the tested
> > devirtualization takes place.
> >
> > Patch has been pre-approved on IRC by Honza, I have tested it with
> > make -k check RUNTESTFLAGS="dg.exp=ipa/devirt-40.C" which I hope is
> > sufficient and I have tested that the pattern matches a call to an
> > OBJ_TYPE_REF in function body in an earlier dump file. I will commit
> > the patch shortly.
> >
> > Thanks,
> >
> > Martin
> >
> >
> > gcc/testsuite/
> >
> > 2014-11-04 Martin Jambor <mjambor@suse.cz>
> >
> > * devirt-40.C: Changed dump to not matching OBJ_TYPE_REF in
> > function body.
> >
> > Index: src/gcc/testsuite/g++.dg/ipa/devirt-40.C
> > ===================================================================
> > --- src.orig/gcc/testsuite/g++.dg/ipa/devirt-40.C
> > +++ src/gcc/testsuite/g++.dg/ipa/devirt-40.C
> > @@ -19,5 +19,5 @@ A::m_fn1 (UnicodeString &, int &p2, UErr
> > UnicodeString a[2];
> > }
> >
> > -/* { dg-final { scan-tree-dump "converting indirect call to function virtual UnicodeString" "fre2" } } */
> > +/* { dg-final { scan-tree-dump-not "\\n OBJ_TYPE_REF" "fre2" } } */
>
> What's the odd newline and spaces here?
That only matches an OBJ_TYPE_REF as a statement in the function body
and specifically does not match
"Determining dynamic type for call: OBJ_TYPE_REF" and
"Starting walk at: OBJ_TYPE_REF"
that are present in the dump file above the dump function.
An alternative would be of course to just scan the optimized dump if
this is considered too much of a hack. But at least I though that for
a testcas it would do nicely.
Martin