This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: That light at the end of the tunnel?
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: esr at grelber dot thyrsus dot com
- Cc: Eric Raymond <esr at thyrsus dot com>, GCC Development <gcc at gcc dot gnu dot org>, Mark Atwood <fallenpegasus at gmail dot com>
- Date: Sat, 21 Jul 2018 09:18:18 -0400
- Subject: Re: That light at the end of the tunnel?
- References: <20180721020451.8E1C43A4AA7@snark.thyrsus.com> <CAGWvnyk00enpOMC+dhC47EBPpB=5EpV1MKik6WpnmOfom5HxwQ@mail.gmail.com> <20180721113158.GA10182@grelber>
On Sat, Jul 21, 2018 at 7:32 AM Eric S. Raymond <esr@grelber.thyrsus.com> wrote:
>
> On Fri, Jul 20, 2018 at 11:13:16PM -0400, David Edelsohn wrote:
> > Have you considered bisecting your recent changes to reposurgeon to
> > determine which one caused the errors in the conversion of GCC Trunk
> > and then trying to reason about why the change causes a problem?
>
> Of course I have.
>
> The problem is this. Whatever I did to break the previously good conversion
> at commit 256000 must have been done to fix breakage turned up at a different
> commit or in one of my test cases. If I revert out whatever change that was
> I won't be at a state of no problens, I'll just have a different problem -
> with no guarantee that it will leave tip conversion in a good state.
>
> No, this needs a root-cause analysis. Reverting back to a previous version
> is unlikely to be helpful, and would be an expensive experiment.
Eric,
I realize that reverting the change would cause another regression.
My suggestion is that the bisection of reposurgeon may be easier /
faster and could help you pinpoint the root cause. Then you could
consider a different solution to the problem that you were trying to
fix with the initial patch. You could see explicitly how the
reposurgeon patch fixes one problem and how it creates a different
problem in Trunk.
Thanks, David