Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode

From: Pip Cet <[email-masked]>
Date: Sat, 27 Feb 2021 17:15:20 +0000

On Sat, Feb 27, 2021 at 1:30 PM Eli Zaretskii <[email-masked]> wrote:
> > However, I'd like to raise a general point:
>
> Is it really useful to present general points, and in a bug discussion
> of all places?  I'd be happy if we had all the non-general points
> figured out, and leave the general ones to people who have more free
> time on their hands, you know?

I agree, but I'll resort to the kindergarten defense. He started it :-)

> > The compiler consists of three stages. The first maps LAP code
> > programs to LIMPLE; the second stage transforms the LIMPLE tree into
> > another LIMPLE tree which is meant still to represent the same
> > program; the third translates LIMPLE to the libgccjit internal
> > representation.
> >
> > Say we've found, as I have, an apparent bug in the second stage: a
> > LIMPLE tree representing one program is transformed into a LIMPLE tree
> > representing another, different program.
> >
> > There are three possibilities:
> >
> > 1. it's easy to construct a preimage of such a LIMPLE tree under the
> > Lisp-to-LIMPLE transformation. Then we most likely have a reproducible
> > miscompilation bug, and we can fix it.
> > 2. it's easy to prove that no erroneously-transformed LIMPLE tree is
> > arrived at by the first stage. In this case, we have no bug.
> > 3. it's difficult to figure out whether the erroneously-transformed
> > LIMPLE tree can arise as a result of Lisp-to-LIMPLE transformation.
> >
> > Case 3 is the difficult one. It's also the most common one, and the
> > one that we were talking about here until I found my example.
> >
> > My strong opinion is that we must treat case #3 as a potential,
> > serious, miscompilation bug. Andrea's opinion, IIUC, is that we should
> > ignore case #3.
>
> My strong opinion is that in the Free Software world (and not only in
> that, but let's forget about the rest for a moment), whoever does the
> job gets to choose the methods and the methodology.  Andrea is doing
> this job, he is our specialist on these issues, and he is developing
> the code and maintaining it.

Absolutely.

> As long as he does that, his opinions
> on the relevant parts of Emacs weigh more than anyone else's, mine
> included.  So if we come up with case #3, and Andrea thinks it's a
> non-issue, I tend to accept his judgment,

That's okay.

If there is judgment. If it is an automated response to the fact that
there's no (Lisp) reproducer included with the bug report, we
shouldn't trust it; we should simply accept that it might still be a
bug.

> especially after he
> responded to your messages with sound reasons.

I take it you've read through the code, understood it all, and
concluded the reasons were "sound", then? (I haven't; I've tentatively
concluded they were unsound, in fact).

("Sound", as I'm sure Eli knows, doesn't mean "sounds good")

> Please understand that any other way, we'd lose Andrea and any other
> volunteers who come to us with significant new features.

I have my own opinions about why Emacs attracts so few volunteers and
drives away so many of those who might be.

> We cannot
> expect them to go to too great lengths doing the job on our terms.

I agree.

> The basic requirements of contributing to Emacs are already not easy
> to satisfy; if we start challenging their technical judgment about
> code they themselves designed and implemented, that'd become
> unbearable.

Again, I have my own opinions about basing recruitment strategies on
those we recruited successfully, rather than including in our sums
those we've driven away.

> > More importantly, when faced with a bug of case #1, Andrea's approach
> > might be to turn it into a case #3. Mine would be to fix it. That's
> > the situation we're in now.
>
> What matters to me at this point is the end result.
> Any issue that
> causes mis-compilation of Lisp programs should be fixed, of course.
> Issues that don't affect the natively-compiled code are much less
> important, and as I explained, my tendency is to accept Andrea's
> judgment on those.

There's a difference between "this issue doesn't affect
natively-compiled code" (which makes it a non-issue, case 2 above) and
"we don't know whether this issue affects natively-compiled code"
(which emphatically does not, case 3 above). Evidence of absence and
all that.

> > > My point is that if those "assume" forms never generate any real code
> > > in the produced .eln file, then why worry about them?
> >
> > They don't generate code themselves, but they affect later stages of
> > the code generation process and thus, ultimately, the real code that
> > results.
> >
> > However, the task of proving that this actually results in a
> > Lisp-to-machine-code bug is, in general, too much to expect the
> > initial discoverer to perform.
>
> The initial discoverer doesn't have to do that, it's enough to raise
> the issue.

Andrea has stated that if there's no reproducer, he doesn't consider
the issue a bug. So "raising the issue" would do, according to the
rules he proposed, precisely nothing.

> The issue has been raised, and it wasn't dismissed: Andrea

Note the "in general" in my statement.

IIUC, you want me to raise future issues and wait for them to be
dismissed rather than complaining, as I am, about the mere
announcement that they will be? That's certainly something I can do,
and resolving that I'll do that would actually be a good result of
this discussion.

> did consider it and did fix a couple of issues you brought up that he
> thought were worth fixing.

Yes. And he said he wouldn't do so in future, for issues of this category.

Pip