Groups | Search | Server Info | Login | Register
Groups > comp.compilers > #3473
| From | gah4 <gah4@u.washington.edu> |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: binary search debugging of compilers |
| Date | 2023-05-17 15:23 -0700 |
| Organization | Compilers Central |
| Message-ID | <23-05-017@comp.compilers> (permalink) |
| References | (2 earlier) <23-05-006@comp.compilers> <23-05-008@comp.compilers> <23-05-011@comp.compilers> <23-05-012@comp.compilers> <23-05-015@comp.compilers> |
On Wednesday, May 17, 2023 at 12:08:27 PM UTC-7, Kaz Kylheku wrote: > On 2023-05-17, gah4 <ga...@u.washington.edu> wrote: > > On Monday, May 15, 2023 at 6:54:08 PM UTC-7, Kaz Kylheku wrote: > > > > (snip) > > > >> Say we have a basket of apples with a rotten smell emanating from it. > >> We can subdivide it, and smell one half and the other. If both halves > >> smell, we know we have two or more rotten apples and they ended up > >> in different halves. This doesn't matter. We just pick one half and > >> keep subdividing. > > But the algorithm described, at least as I remember it, doesn't test both > > halves. > If the problem reproducews with the half you're testing, you assume > the misprocessed function is in that half. (There could be a bad > function in the other half also, and you could test that, but it's > unnecessary.) > > If the problem deosn't reproduce in the half you're testing, you > assume the misprocessed functions lie in the other half, and > recurse on that half instead. I was mostly noting it, as the apple test was written to test both halves. > The algorithm will work even if every single function is miscompiled. > (And will take the same logarithmic number of steps, since we cut > in half no matter what.) > It will arbitrarily narrow it down to one, showing that even if the > compiler change is enabled for just one function, there is a problem. > That function can be investigated. Then maybe then the fix solve the > issue for the five hundred other broken functions, too. As to the problem of debugging by miscompiled code, this reminds me of stories of debugging compilers by feeding them cards from the card recycling bin. It seems that cards were especially high grade paper and so worth keeping separate for recycling. I never actually saw anyone do that, though. In my younger days, some said that I was especially good at finding compiler errors. Maybe not as good now. I would try things that were allowed, but others might not have thought about doing. Only one I remember now, is a C compiler that miscompiled the ++ operator on a double variable. Allowed in C, but maybe not often used.
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
binary search debugging of compilers Russ Cox <rsc@swtch.com> - 2023-05-12 13:59 -0400
Re: binary search debugging of compilers Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-13 03:20 +0000
Re: binary search debugging of compilers Fernando <pronesto@gmail.com> - 2023-05-13 04:47 -0700
Re: binary search debugging of compilers Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-14 02:49 +0000
Re: binary search debugging of compilers gah4 <gah4@u.washington.edu> - 2023-05-14 13:38 -0700
Re: binary search debugging of compilers Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-15 21:52 +0000
Re: binary search debugging of compilers gah4 <gah4@u.washington.edu> - 2023-05-16 23:52 -0700
Re: binary search debugging of compilers Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-17 18:28 +0000
Re: binary search debugging of compilers gah4 <gah4@u.washington.edu> - 2023-05-17 15:23 -0700
Re: binary search debugging of compilers Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-19 03:21 +0000
Re: binary search debugging of compilers Thomas Koenig <tkoenig@netcologne.de> - 2023-05-19 21:59 +0000
Re: binary search debugging of compilers gah4 <gah4@u.washington.edu> - 2023-05-20 20:20 -0700
Re: Old C compilers, binary search debugging of compilers Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-05-22 09:05 +0200
binary search debugging of compilers Max B <tekk.nolagi@gmail.com> - 2023-05-19 16:31 -0500
Re: binary search debugging of compilers Thomas Koenig <tkoenig@netcologne.de> - 2023-05-14 19:59 +0000
Re: binary search debugging of compilers Cameron McInally <cameron.mcinally@nyu.edu> - 2023-05-14 23:28 -0400
Re: binary search debugging of compilers Kaz Kylheku <864-117-4973@kylheku.com> - 2023-05-15 21:35 +0000
csiph-web