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

[Pip Cet]

On Fri, Feb 26, 2021 at 8:12 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Pip Cet <pipcet@gmail.com>
> > Date: Thu, 25 Feb 2021 20:59:41 +0000
> > Cc: 46670@debbugs.gnu.org, Mauricio Collares <mauricio@collares.org>
> >
> > > On this subject I highly recommend the following, let's adopt what we
> > > essentially do for GCC development:
> >
> > You might want to suggest that on emacs-devel, as it would be a very
> > drastic change.
>
> AFAICT, the principles proposed by Andrea are just common sense, and
> definitely not a drastic change from our existing practices.

Let me try to explain a situation in which I don't think they work
very well, and which may or may not be similar to the situation we're
actually in:

1. We're emitting strange "assume" insns.
2. These are pseudo-insns which are not rendered into functional code.
3. We do not have a facility for converting these "assume" insns into
functional code which asserts they hold at runtime.
4. We have test cases which ensure the "assume" insns are actually
generated as they currently are.

How, assuming for the moment that the "strange" in (1) actually means
"buggy", are we supposed to fix this?

A patch changing (1) will be rejected as invalid because there is no
reproducer. It will also be rejected as broken because the test cases
will fail.
A patch changing (2) (e.g. a new compiler feature which makes use of
the assumes) will be rejected as broken because it will generate
incorrect code.
A patch changing (3) will be rejected because the new assertions will
initially fail, because of (1).
A patch changing (4) will be rejected because it would mean dropping
tests which appear to work.

A patch changing (1), (3), and (4) at the same time will be rejected
because it wouldn't be incremental.

I think, but am willing to be convinced I'm wrong, that this is the
situation we're in. I can prepare patches changing any combination of
(1), (2), (3), and (4).

Pip