This is the mail archive of the
mailing list for the GCC project.
Re: hints for identifying a problem patch?
- From: mike stump <mrs at windriver dot com>
- To: gcc at gcc dot gnu dot org, janis187 at us dot ibm dot com
- Date: Thu, 2 May 2002 13:24:51 -0700 (PDT)
- Subject: Re: hints for identifying a problem patch?
- References: <20020502130515.A5334@us.ibm.com>
> Date: Thu, 2 May 2002 13:05:15 -0700
> From: Janis Johnson <firstname.lastname@example.org>
> To: email@example.com
> I suspect that my attempts to find out which patch caused a
> particular test to start failing are horribly inefficient. Can
> people who do this sort of thing regularly please share some hints?
> Once I understand a good way to do it I'll write up some directions
> to include in the web pages somewhere. On the other hand, if such
> documentation already exists, it needs to be easier to locate.
>From the compliers 101 class:
Sure, you build once a day from cron, and then you save of the cc1 or
the cc1plus to a special directory, and give it a name like
cc1plus-020502, and then when someone complains you say:
for i in cc1plus-*; do
$i -quiet -O2 test.ii && grep -s r7 test.s
if [ $? = 0 ]; then echo pass: $i; else echo fail: $i; fi
and viola, utterly trivial, runs very fast, and you get daily coverage
for the last year or two, and you can answer complex questions in
seconds to minutes.
You can also track things like, when did it slow down, when did it eat
up 100MB of swap, when did the .text balloon to be 4x larger, when did
that symbol go undefined...