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

[Pip Cet]

On Sat, Feb 27, 2021 at 10:24 AM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Sat, 27 Feb 2021 09:39:50 +0000
> > Cc: Andrea Corallo <akrl@sdf.org>, 46670@debbugs.gnu.org, 
> > mauricio@collares.org
> >
> > > > How, assuming for the moment that the "strange" in (1) actually means
> > > > "buggy", are we supposed to fix this?
> > >
> > > I don't see any evidence yet that this needs to be fixed.  Without
> > > such evidence, the whole discussion is about a moot point.
> >
> > Quite the reverse: if we make rules saying such bug reports are to be
> > ignored, as Andrea suggested, actually reporting the bug is moot. It's
> > the rules I objected to in the previous mail, not the legitimate
> > requirement for further elaboration on my part before anyone else is
> > convinced there's a bug.
>
> Reports are never ignored, because someone needs to read them before
> deciding whether they need any action.  But that's beside the point.

"Deciding something doesn't need any (actual) attention" is pretty
close to the dictionary definition of "ignore".

After some playing around, I've now found a Lisp reproducer that is
mis-compiled because of the bug I reported.

However, I'd like to raise a general point:

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.

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.

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

> They are like
> comments: if you don't like comments, just ignore them; they don't
> actually affect any executable code.

They're not. We could redefine them to be, but we'd first have to
remove all code that uses them. And then that would leave us with
LIMPLE constructs that are quite literally meaningless.

> > All of this was sufficient for me to write Andrea asking whether there
> > was an issue (leaving out what I thought would be, to him, the tedious
> > trivialities of the lines above), or whether I was confused. I could
> > certainly have handled the ensuing exchange better, and I'll try to do
> > so in the future. However, the categorical instalment of new rules
> > disallowing the presentation of patches or bug reports for all bugs
> > outside a very narrow class would prevent that entirely.
>
> There are no rules that disallow presentation of patches.

Thanks for clarifying that.

Pip