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

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> gmail.com>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 46670 <at> debbugs.gnu.org, Mauricio Collares <mauricio <at> collares.org>
Subject: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode
Date: Wed, 24 Feb 2021 07:00:22 +0000

[Message part 1 (text/plain, inline)]

Hello Andrea,

by the way, I'm mostly still pursuing it because it keeps flushing out
bugs in comp.el :-) I'm attaching another one, though I'm not sure the
bug in question can actually be triggered without modifying the byte
compiler.

On Tue, Feb 23, 2021 at 10:55 PM Andrea Corallo <akrl <at> sdf.org> wrote:
> Pip Cet <pipcet <at> gmail.com> writes:
> >> >> > We don't have to, let's just not emit an assume about a variable that
> >> > we just introduced and that's never read?
> >>
> >> We disagree :)
> >
> > We can disagree about the "let's" part (and should, of course), but we
> > should agree about the "we don't have to" part, because that's a
> > matter of fact, not opinion.
>
> This new mvar *is* used, actually by an assume.

I said it was never read, which I agree is more correct.

> And the assume in
> discussion is targetting a live variable that will be used by functional
> code so I really see no scandal here.

Only on one side of the assume. The other side holds a new "temporary"
variable which is assumed to be equal to something that it isn't
actually equal to, and that seems very scandalous to me.

> >> As the byte compiler does not care about propagating types and values it
> >> can just clobber the variable, here we aim for more so we need it to
> >> keep it live till the assume.
> >
> > If we decide the variable needs to be kept live, the byte compiler
> > should keep it live, not us.
>
> Again no, any pass in the compiler must have the right to create new
> temporaries for whichever purpose it wants, and indeed we can't expect

I agree with that part, by the way. We should, at some point in the
future when we need it, add the ability to introduce temporary
variables (and remove them), in a clean, well-considered fashion. At
present, we don't need it, we lack the ability to remove such
variables, and I'm afraid the last parts can be disputed, too.

[0001-Fix-ICE-when-compiling-an-explicit-call-to-single-ar.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.