https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99694
--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Haoxin Tu from comment #7) > (In reply to Martin Liška from comment #1) > > Confirmed, started with r9-7156-g33579b59aaf02eb7. > > Hi Martin. I am sorry to bother you, and I just have a question about how to > find a bad commit quickly in GCC. Hello. You don't have to find a bad revision, we can easily do that. > > As far as I know, we can use git bitset to set a bad and good commit to then > apply binary search to find the exact place that caused the error(I usually > do like this). My question is, is this means I should always find a commit > (to be tested), then build the source code and run the given test case to > tell a bad/good result? My concern is that build a GCC from a source code > may take a relatively long time (maybe more than half an hour), so if the > number of commits is much, it will take a long time to find the error > commit. Is my understanding correct or not? I have a script which I use: https://github.com/marxin/script-misc/blob/master/gcc-bisect.py I can do quick bisection as I have built binaries for all GCC revisions for a couple last years. > > Also, I am wondering if you are using an automatic tool or other approaches > that can quickly find the bad commit to cause the problem. If I learned how > to do this quickly, I'd like to do the bitset myself and tell the bad commit > when I submit a report next time. > > Please correct me if I am wrong and any suggestions are welcome! Thank you > very much! We thank you for a nice bug report. Keep doing :) Martin > > > Best, > Haoxin
