From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode Date: Sat, 27 Feb 2021 09:39:50 +0000 Message-ID: References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26060"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46670@debbugs.gnu.org, mauricio@collares.org, Andrea Corallo To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 27 10:41:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lFw62-0006gl-E4 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 10:41:10 +0100 Original-Received: from localhost ([::1]:40124 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFw61-00016v-H7 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 04:41:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43094) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lFw5u-00016d-HJ for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 04:41:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59863) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lFw5u-0006Ye-AB for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 04:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lFw5u-0000vc-6k for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 04:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Feb 2021 09:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46670 X-GNU-PR-Package: emacs Original-Received: via spool by 46670-submit@debbugs.gnu.org id=B46670.16144188373530 (code B ref 46670); Sat, 27 Feb 2021 09:41:02 +0000 Original-Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 09:40:37 +0000 Original-Received: from localhost ([127.0.0.1]:43176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFw5U-0000us-Vi for submit@debbugs.gnu.org; Sat, 27 Feb 2021 04:40:37 -0500 Original-Received: from mail-ot1-f46.google.com ([209.85.210.46]:34007) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFw5Q-0000uc-2P for 46670@debbugs.gnu.org; Sat, 27 Feb 2021 04:40:35 -0500 Original-Received: by mail-ot1-f46.google.com with SMTP id h10so900708otm.1 for <46670@debbugs.gnu.org>; Sat, 27 Feb 2021 01:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fCFlUwsN4a8OdkboZM51jZmg7DKWxPe2Xu+nslB7g0c=; b=lVIrvQPnA6UPxsbeUMlWxY8Pvn7o8Xuv33UP5MGlYKii1fDso+pMoI+CKJXUoel+k4 XrHR10+aIbGlh5MumWd9mLWuoO2bD4Hx8GswTcPsclha418udOSZ6NmTfE+jkd6635X9 9coWuCs+06gu5nQv/rLreuAmDjdgGVTLkpguMam+80WlHjnYqnDfU32imz0+iNo3bwPg BxVa/D+vj1iAq0qARNtANjAZgp5WkOMg1kjvAfc4vMr5v/R+QjbHEuP07ehbYuDFa2y8 0roVpFGb6c50+kNFnfDWf2U/XczG78zU7Nu+CRBg2eWPFdZMyJOS2G3VosC7iNvuXD7e mVEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fCFlUwsN4a8OdkboZM51jZmg7DKWxPe2Xu+nslB7g0c=; b=guzf+UQgbF/OFYwhz/RF9RueuzsqewIcta8KwovxaYBee+MRfJ/51jDiDjWLzgpI0O Dl2+m8FVwkHeygjaLjqtSbK3Niqa1zqvL9RQpd9mfHvgsYXbfEajQs0/It67Vl58vxxu dULX7bPu/3it7wxtHJ3YDN4kBjG9hhA6i4Vvf/Ca3vY+2cGF2rzKzofPzwjnIzgmw64+ YnCxnocMyu1+8JgvFQmLUwi/19xR9WyyAChqkcrytM6c0fiQn/oSDBuvDgJO7duUsI8z h34oMjb+jaWgB1TAKHPTxxvzETRhRDJ1Rkdf5rirAFwRLID11sRldsbHUTNk6PhaGtcQ sKCA== X-Gm-Message-State: AOAM53182ct1FdTaa8TEpBwsm+vICvhfYd9+tOdc7fFxCMG+uTxA1vZ5 6kN/EPALSmQxYkQCslmu1QjYiuuUNCXW8ylO24E= X-Google-Smtp-Source: ABdhPJw9bK8w1vR7Z6a7xFTES0Q6qyyuU1j6KiU+F+xpAhevSpqi0gjCVQf8a1q4AcHbXv/NJPhiWT7Fk0cbxGinKww= X-Received: by 2002:a05:6830:3090:: with SMTP id f16mr5714601ots.292.1614418826500; Sat, 27 Feb 2021 01:40:26 -0800 (PST) In-Reply-To: <835z2eosqn.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:200930 Archived-At: On Sat, Feb 27, 2021 at 7:49 AM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sat, 27 Feb 2021 05:06:43 +0000 > > Cc: Andrea Corallo , 46670@debbugs.gnu.org, mauricio@collares.org > > > > > 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: [...] > > 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. > Maybe I don't understand the issue well enough? I'm certainly in no position to say I understand it perfectly and I can explain it to you. The problem is that "assume" insns do not have semantics yet: they don't behave as you would expect "assume" to behave; they aren't documented to behave differently; and there is no code (yet) which uses them in ways that would make clear what they are supposed to mean. There is, I am convinced, no consistent way of _giving_ them semantics without changing the assume insns we emit, first. For example, we're emitting <#(mvar Y :slot 1) is live> (assume #(mvar X :slot 1) (not #(mvar Y :slot 1))) <#(mvar X :slot 1) is live> That's paradoxical on the face of it, as the two mvars refer to the same variable. If there is a consistent nontrivial interpretation of "assume" that would work in this case, I'm unaware of it. Note that "assume" as we know and love it has very simple semantics: it expresses a condition which, at runtime, is known to be satisfied. You can convert an assume into a runtime test, and if it fails, the assume was wrong in the first place. That's not the case here, since the assume above would translate into (assert (not (eq #(mvar X :slot 1) #(mvar Y :slot 1)))) which, obviously, never succeeds. The fix is as trivial as not saying that the mvar X lives in slot 1. There's actually a different slot that it does live in, and my patch would have used that slot instead. It would have been equally valid simply not to give it a slot at all, by whichever mechanism is appropriate for that (I would have left the slot slot nil, but if Andrea prefers assigning a negative "virtual" slot number to the mvar, that's a valid choice as well). There's a very similar issue with the other branch of the "if", as it turns out. 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. Pip