[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affect
From: |
Pip Cet |
Subject: |
bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode |
Date: |
Wed, 24 Feb 2021 07:00:22 +0000 |
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@sdf.org> wrote:
> Pip Cet <pipcet@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
Description: Text Data
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, (continued)
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Pip Cet, 2021/02/27
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Eli Zaretskii, 2021/02/27
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Pip Cet, 2021/02/27
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Eli Zaretskii, 2021/02/27
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Pip Cet, 2021/02/27
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Eli Zaretskii, 2021/02/27
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Pip Cet, 2021/02/28
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Andrea Corallo, 2021/02/22
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Pip Cet, 2021/02/23
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode, Andrea Corallo, 2021/02/23
- bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode,
Pip Cet <=