From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode Date: Sat, 27 Feb 2021 15:30:01 +0200 Message-ID: <83o8g5ocyu.fsf@gnu.org> References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36505"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46670@debbugs.gnu.org, mauricio@collares.org, akrl@sdf.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 27 14:31:09 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 1lFzgb-0009Py-5S for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 14:31:09 +0100 Original-Received: from localhost ([::1]:34240 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFzga-0005ag-8Z for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 08:31:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46086) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lFzgT-0005aM-Sz for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 08:31:01 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60069) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lFzgT-0005Tx-Ly for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 08:31:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lFzgT-0000D0-JP for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 08:31:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Feb 2021 13:31:01 +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.1614432627762 (code B ref 46670); Sat, 27 Feb 2021 13:31:01 +0000 Original-Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 13:30:27 +0000 Original-Received: from localhost ([127.0.0.1]:43382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFzfv-0000CD-57 for submit@debbugs.gnu.org; Sat, 27 Feb 2021 08:30:27 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFzfu-0000C2-7T for 46670@debbugs.gnu.org; Sat, 27 Feb 2021 08:30:26 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59574) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFzfn-0005CP-5U; Sat, 27 Feb 2021 08:30:20 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3114 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lFzfg-0002Io-JV; Sat, 27 Feb 2021 08:30:18 -0500 In-Reply-To: (message from Pip Cet on Sat, 27 Feb 2021 12:39:48 +0000) 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:200942 Archived-At: > From: Pip Cet > Date: Sat, 27 Feb 2021 12:39:48 +0000 > Cc: Andrea Corallo , 46670@debbugs.gnu.org, mauricio@collares.org > > However, I'd like to raise a general point: Is it really useful to present general points, and in a bug discussion of all places? I'd be happy if we had all the non-general points figured out, and leave the general ones to people who have more free time on their hands, you know? > 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. My strong opinion is that in the Free Software world (and not only in that, but let's forget about the rest for a moment), whoever does the job gets to choose the methods and the methodology. Andrea is doing this job, he is our specialist on these issues, and he is developing the code and maintaining it. As long as he does that, his opinions on the relevant parts of Emacs weigh more than anyone else's, mine included. So if we come up with case #3, and Andrea thinks it's a non-issue, I tend to accept his judgment, especially after he responded to your messages with sound reasons. Please understand that any other way, we'd lose Andrea and any other volunteers who come to us with significant new features. We cannot expect them to go to too great lengths doing the job on our terms. The basic requirements of contributing to Emacs are already not easy to satisfy; if we start challenging their technical judgment about code they themselves designed and implemented, that'd become unbearable. > 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. What matters to me at this point is the end result. Any issue that causes mis-compilation of Lisp programs should be fixed, of course. Issues that don't affect the natively-compiled code are much less important, and as I explained, my tendency is to accept Andrea's judgment on those. > > 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. The initial discoverer doesn't have to do that, it's enough to raise the issue. The issue has been raised, and it wasn't dismissed: Andrea did consider it and did fix a couple of issues you brought up that he thought were worth fixing. What's left now is just the gray area, where I trust Andrea more than anyone else.