[PATCH] Fix dump scan in test devirt-40.C

Richard Biener richard.guenther@gmail.com
Tue Nov 4 16:20:00 GMT 2014


On Tue, Nov 4, 2014 at 4:57 PM, Martin Jambor <mjambor@suse.cz> wrote:
> 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.

Ah ok.

Thanks,
Richard.

> 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



More information about the Gcc-patches mailing list