This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: hints for identifying a problem patch?


> Date: Thu, 2 May 2002 13:05:15 -0700
> From: Janis Johnson <janis187@us.ibm.com>
> To: gcc@gcc.gnu.org

> 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
done

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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]