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

[Eli Zaretskii]

> From: Pip Cet <pipcet@gmail.com>
> Date: Sat, 27 Feb 2021 12:39:48 +0000
> Cc: Andrea Corallo <akrl@sdf.org>, 46670@debbugs.gnu.org, 
> mauricio@collares.org
> 
> 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?

> 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.  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, especially after he
responded to your messages with sound reasons.

Please understand that any other way, we'd lose Andrea and any other
volunteers who come to us with significant new features.  We cannot
expect them to go to too great lengths doing the job on our terms.
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.

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

> > 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.  The issue has been raised, and it wasn't dismissed: Andrea
did consider it and did fix a couple of issues you brought up that he
thought were worth fixing.  What's left now is just the gray area,
where I trust Andrea more than anyone else.