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 12:39:48 +0000 Message-ID: References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.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="25840"; 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 13: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 1lFyuF-0006dA-JL for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 13:41:11 +0100 Original-Received: from localhost ([::1]:46330 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFyuE-0004dh-5m for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 27 Feb 2021 07:41:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37766) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lFyu7-0004da-Dn for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 07:41:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60041) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lFyu6-0008Ar-Kb for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 07:41:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lFyu6-0007Um-I7 for bug-gnu-emacs@gnu.org; Sat, 27 Feb 2021 07: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 12: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.161442963728774 (code B ref 46670); Sat, 27 Feb 2021 12:41:02 +0000 Original-Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 12:40:37 +0000 Original-Received: from localhost ([127.0.0.1]:43354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFytg-0007U2-I8 for submit@debbugs.gnu.org; Sat, 27 Feb 2021 07:40:36 -0500 Original-Received: from mail-ot1-f53.google.com ([209.85.210.53]:44903) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFyta-0007Tk-NY for 46670@debbugs.gnu.org; Sat, 27 Feb 2021 07:40:34 -0500 Original-Received: by mail-ot1-f53.google.com with SMTP id f33so11772231otf.11 for <46670@debbugs.gnu.org>; Sat, 27 Feb 2021 04:40:30 -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=2T6WENjs8eJ7v0kPxslBNoxydpBpF+CwwsjtrcoGRvQ=; b=YUd5xjLPPA7n1zTGAl9b3sYAb553gqFgZAn4oJuuxxzGJwC5CH/VzSca0Ep2qWUwOy NVLMDvaFYoRgK07sP/tdzssJPk52a5q8g/6PtkPNWq5F0DIjtI7nyfUARLwhsJupXcjH uh+qoZJxsYF+/npoOmwZUCkhr7OHlQ3nt2q+bgATSpx7ZHW1LKvCgOQbYmiFTC5OmkVL WTle5hHpXcMUeD7J/FJqMrBBOQ4q8bYzbbp2YiDRZH9W26+vXwBsUvUNi/fEeUL+8uQ/ YLDNSE3eDJSgQqRq6CGLJSnzdmmxF48mtTmfla9cUl8m5vmVwjkMoXxqxBLdsM1IsZZ7 KiZQ== 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=2T6WENjs8eJ7v0kPxslBNoxydpBpF+CwwsjtrcoGRvQ=; b=bW89qFSoZbFxUzMW7wDWM9Z5nKSIXgvGxhSJaebcxuXUtQJHeXBSGLaDlbx3rSj0ld yVML50I/Z3xQtbNqRAcQI0xrY4mw20KODBZ/E+9FyIXyKAt3mDmWjUFQPKFHHdOLT9qP IzI4mA/JUvh4vkACWlCLRPmKtUGd4Hw/OAJO6GnTAY23pvruiR3686+C4Rsz14tBMlYm +LCY00ref1Wzl64TVEsd2nchRIAK5OvNL/Bljw5hoew/jHZz6LTUjoLsB/KskbuexaIk kM54r8sZCdk53L+PlRsUbZHiNr422WfkqujPlFqjhPtAF7Ou6k6nTuyk9BlTD0qM9nUu WTSQ== X-Gm-Message-State: AOAM531vHKWiazbVyMljowHqOVr+QsqbeLu6mZYM1YifTucDPxCMs7sx q96nGnQw8DLOfIcDbZUjgsvzd5csGO/EHV0ooPU= X-Google-Smtp-Source: ABdhPJxkExPXV7+aOFlkUM1bxJogKP7cFy1y3fbxUcyttSzTJ6vYdFEVHPyzGRulBbnlFBEjVZFu882mHrnmfS5rYy0= X-Received: by 2002:a05:6830:3090:: with SMTP id f16mr6119711ots.292.1614429625088; Sat, 27 Feb 2021 04:40:25 -0800 (PST) In-Reply-To: <83v9adolkk.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:200938 Archived-At: On Sat, Feb 27, 2021 at 10:24 AM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sat, 27 Feb 2021 09:39:50 +0000 > > Cc: Andrea Corallo , 46670@debbugs.gnu.org, mauricio@collares.org > > > > > > 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. > > Reports are never ignored, because someone needs to read them before > deciding whether they need any action. But that's beside the point. "Deciding something doesn't need any (actual) attention" is pretty close to the dictionary definition of "ignore". After some playing around, I've now found a Lisp reproducer that is mis-compiled because of the bug I reported. However, I'd like to raise a general point: 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. 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. > 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. > They are like > comments: if you don't like comments, just ignore them; they don't > actually affect any executable code. They're not. We could redefine them to be, but we'd first have to remove all code that uses them. And then that would leave us with LIMPLE constructs that are quite literally meaningless. > > 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. > > There are no rules that disallow presentation of patches. Thanks for clarifying that. Pip