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 17:15:20 +0000 Message-ID: References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.fsf@gnu.org> <83o8g5ocyu.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="33988"; 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 18:17:15 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 1lG3DP-0008jp-3p for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 18:17:15 +0100 Original-Received: from localhost ([::1]:48462 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lG3DO-0005F9-6r for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 12:17:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lG3DC-0005Ef-4l for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 12:17:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33733) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lG3DB-0006i9-Tj for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 12:17:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lG3DB-0001xo-Pf for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 12:17:01 -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 17:17: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.16144461667482 (code B ref 46670); Sat, 27 Feb 2021 17:17:01 +0000 Original-Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 17:16:06 +0000 Original-Received: from localhost ([127.0.0.1]:45279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lG3CH-0001wb-Kr for submit@debbugs.gnu.org; Sat, 27 Feb 2021 12:16:06 -0500 Original-Received: from mail-oi1-f176.google.com ([209.85.167.176]:46401) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lG3CF-0001vK-Am for 46670@debbugs.gnu.org; Sat, 27 Feb 2021 12:16:03 -0500 Original-Received: by mail-oi1-f176.google.com with SMTP id f3so13352234oiw.13 for <46670@debbugs.gnu.org>; Sat, 27 Feb 2021 09:16:03 -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=Am7q48VR6wnTNO+6CfwOnzPUBKA2/vaivBTlLeKJdqQ=; b=n2e22cOBn5exlwldsscLcT1r7d5+x6nnRfA2qQcvMrBvzheaOoheddPwSsbRZvUCi8 MXbjf+c9UTVTeRJRVNHz7IPM61urYPSMRmjbGaC1yEoAfmvRlgrY2dvhdoeve95Z1PS4 ovMgv6R2pag/F82NbnQ3D36cTVHDu/JUmT8kZ1D55S7HQvPoQpeFUK6MfiBHlwvN7Kwx drZlX4uUI9/GvdhYu8yrpNF3xa3yRBCxw+ncVL7jU02VsQTtSAyxzAfUm6mNfIomgyPe ZVt1BpSpk6J2WnBZTpayaAfmm3n8AsaBnInLSivktD/dpMCCsCVuKEkXlpT0qrW4WANs LGeA== 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=Am7q48VR6wnTNO+6CfwOnzPUBKA2/vaivBTlLeKJdqQ=; b=C3Inmr9zSgHtSmwUzZ+J6qeKdO03/kopz/6aTmzgZKlcUn9Bsn7iSwR9xKYavri+PC ZV/LD5Vt8S+uzGOm/8z3sdWpWDbqoloXykfzOBSsIfr2Nb+Jrb/Wbf8JZjsgPJUqAjH9 Sq8wniz4kGhDFpOVtAnQFPTtLa7BH2Ir8xLVwNlY2muh3m1loNFeP3zzsH/K4+koOlbs +v+/Nly7fwt2JsZcpZ5noqhBmcNYaxHN+EGKJkSEHlFLkRHnA9p8WS1C0D0YmNQdSi4x StKiJiRdxmu30QnUz0Vq9VshBeCRFUPnaVsQXgNVFqySAG4D1BGEfaVUUruMmNje5Fd7 al8A== X-Gm-Message-State: AOAM530YKWIMGLsC5+VwKqkn/vI0kuzsmjF0AmTS304OmlDM5IDs6dxY D98fTxBPjHFEPO+n5thQJ2hkbHNssKnRZ9LV/Us= X-Google-Smtp-Source: ABdhPJy7ndSlZss1S/l8HjmYtc8pX97+pIAnT+r4D1KdAA4GxUrpn+VmFQPvmPAAa3C5tH5oxyqf/8gTrDDaYlGgKHg= X-Received: by 2002:aca:aad6:: with SMTP id t205mr4123197oie.122.1614446157533; Sat, 27 Feb 2021 09:15:57 -0800 (PST) In-Reply-To: <83o8g5ocyu.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:200962 Archived-At: On Sat, Feb 27, 2021 at 1:30 PM Eli Zaretskii wrote: > > 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? I agree, but I'll resort to the kindergarten defense. He started it :-) > > 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. Absolutely. > 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, That's okay. If there is judgment. If it is an automated response to the fact that there's no (Lisp) reproducer included with the bug report, we shouldn't trust it; we should simply accept that it might still be a bug. > especially after he > responded to your messages with sound reasons. I take it you've read through the code, understood it all, and concluded the reasons were "sound", then? (I haven't; I've tentatively concluded they were unsound, in fact). ("Sound", as I'm sure Eli knows, doesn't mean "sounds good") > Please understand that any other way, we'd lose Andrea and any other > volunteers who come to us with significant new features. I have my own opinions about why Emacs attracts so few volunteers and drives away so many of those who might be. > We cannot > expect them to go to too great lengths doing the job on our terms. I agree. > 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. Again, I have my own opinions about basing recruitment strategies on those we recruited successfully, rather than including in our sums those we've driven away. > > 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. There's a difference between "this issue doesn't affect natively-compiled code" (which makes it a non-issue, case 2 above) and "we don't know whether this issue affects natively-compiled code" (which emphatically does not, case 3 above). Evidence of absence and all that. > > > 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. Andrea has stated that if there's no reproducer, he doesn't consider the issue a bug. So "raising the issue" would do, according to the rules he proposed, precisely nothing. > The issue has been raised, and it wasn't dismissed: Andrea Note the "in general" in my statement. IIUC, you want me to raise future issues and wait for them to be dismissed rather than complaining, as I am, about the mere announcement that they will be? That's certainly something I can do, and resolving that I'll do that would actually be a good result of this discussion. > did consider it and did fix a couple of issues you brought up that he > thought were worth fixing. Yes. And he said he wouldn't do so in future, for issues of this category. Pip