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: Thu, 25 Feb 2021 12:41:42 +0000 Message-ID: References: <87a6ry46uc.fsf@collares.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="36423"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46670@debbugs.gnu.org, Mauricio Collares To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Feb 25 13:43:12 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 1lFFz6-0009OK-43 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Feb 2021 13:43:12 +0100 Original-Received: from localhost ([::1]:42934 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFFz5-00043W-5K for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 25 Feb 2021 07:43:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58580) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lFFyx-000433-7H for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2021 07:43:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53613) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lFFyw-0004rE-8k for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2021 07:43:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lFFyw-00007P-5y for bug-gnu-emacs@gnu.org; Thu, 25 Feb 2021 07:43: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: Thu, 25 Feb 2021 12:43: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.1614256949411 (code B ref 46670); Thu, 25 Feb 2021 12:43:02 +0000 Original-Received: (at 46670) by debbugs.gnu.org; 25 Feb 2021 12:42:29 +0000 Original-Received: from localhost ([127.0.0.1]:36926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFFyO-00006Y-M3 for submit@debbugs.gnu.org; Thu, 25 Feb 2021 07:42:28 -0500 Original-Received: from mail-oi1-f170.google.com ([209.85.167.170]:42630) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFFyK-00006K-Ky for 46670@debbugs.gnu.org; Thu, 25 Feb 2021 07:42:27 -0500 Original-Received: by mail-oi1-f170.google.com with SMTP id l64so5903122oig.9 for <46670@debbugs.gnu.org>; Thu, 25 Feb 2021 04:42:24 -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=LeG8jyyiMQUuZbTpL9V45Ol2CrZjkYCp/PEy90mw8Fs=; b=iLY1z7vcJNzveZc7sGFYC6C9LTxkMRpU1mx8amb+HaWyfmUU9An7GTwjqpl3jCNj6M 1zeF9LH/MOpoLPWM4tT641LS/QOvhoUZrVfK0Xe26EkO56e1JgH0nTx3QRCk4ex1tDPZ fld/zXj2/R1aZPu757BJ2gSXFo4dE+GyvVxft+l3CzUDbNDW9wz23VGCD4lw+0es2BFl NhtPkrHhdTvwXmfoLuLwuRMzaVOYtmHiafZs5jDL2ANeOn9tXp60inPy+c/kFEQjs6pD SwQofANMFY+8QG6klh9tP9BO1Mxteoxal7Q8J83Wvc5zVab5phQo6kOjtc08gcQnX5vJ 34kQ== 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=LeG8jyyiMQUuZbTpL9V45Ol2CrZjkYCp/PEy90mw8Fs=; b=eh+HiYHLrrKF7B6CzolgfZvCzxpXGi3EeAlIXjJ4nnErdn/u9UqdwCrqigl+eSyrWr gpx8/aV7mgrHdw3TprZ7Li7DlAQhIbRrp2sOZyb3AqvJNfu3xBZzdYedIO1G80t/e35v OCVHzfs4p+6xIabyFiLqEDNqraw+QWinI/0XqA7KYHvm4MM8KjTLIbnU29lTG+am92OY R7hS1KQenLzhwEMeB/0E2btd/zNedV9A7j0qnXEZ1xSbtoZ+wst8eVqjV4QsNBoVW0R+ bQVf/UkDMo0Sc3Cf8lDw/l9kmkPwsBeTNQGhtC8sbBR6EYB6uL/JP2edgwBQ88OCi/Qj Ecbg== X-Gm-Message-State: AOAM531xQ1OPK7QfDUMMXWQK/LQiKa53eXTn24AdTc+th3CXB/I8XWwb YF5Myi1YxbPFnrvL7NnMbR2ipDRtKjEb9foEoKboWlENRaDtgA== X-Google-Smtp-Source: ABdhPJwTDaHcdxj9YsgngaH+plFxHiHZ6jNderHJvXSiSt3m8wSgIe6mykc/6vYNEBeZpfp1vweTgJrZdcXcyC4w9F8= X-Received: by 2002:aca:4c5:: with SMTP id 188mr1772266oie.44.1614256938945; Thu, 25 Feb 2021 04:42:18 -0800 (PST) In-Reply-To: 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:200776 Archived-At: Hello Andrea, On Wed, Feb 24, 2021 at 10:06 AM Andrea Corallo wrote: > > Pip Cet writes: > > > On Wed, Feb 24, 2021 at 9:42 AM Andrea Corallo wrote: > >> (assume #(mvar 22593374 2 (not (integer 3 3))) (not #(mvar 22590962 2 (integer 3 3)))) > > > > If that doesn't mean "the variable in slot 2 is not equal to the > > variable in slot 2", we desperately need to work on the LIMPLE > > syntax... > > Honestly I think would be fair from your side to first try to understand > how it works before criticizing it or submitting untested patches. I thought I'd give this some time to let tempers cool. I appreciate your criticism (but not the ad hominem), and I will take it into account when communicating with you. I'm sorry you mistook the patches I sent as being submitted for immediate inclusion: so far, that hasn't been my intention. They're meant to demonstrate ideas and indicate which area I'm working on. I'll try to make that clear in future. As for the immediate issue: LIMPLE, of course, is yours to define as you wish. If, however, you don't define it, either in documentation or by providing code that handles it correctly, you can hardly blame me for considering it a bug if the obvious interpretation causes subtle, unnecessary problems. To pick an example at random, after your recent changes, I assumed the following would be valid LIMPLE (pseudocode): (set (mvar :slot -1) (mvar :slot 0)) but it's not, because negatively-indexed "temporary variables" aren't actually mapped to variables in the C backend (instead, they generate out-of-bounds array accesses, usually a SIGSEGV). If that is intentional, we need to document it (we also need to assert rather than segfault when someone disregards this capricious rule) . If it is unintentional, and I believe it is, do you really want me not to point it out? Lastly, on the subject of testing, I believe compiler correctness is fundamentally more important than not missing any optimizations. Most of your tests cover the latter aspect. Maybe we could express that in the tests somehow, by using another tag? > Indeed I'm happy to answer as I've explained what this means in my > previous mail. I'm not sure I understand that sentence. I'll try looking through previous messages from you for an explanation, I guess? > And I've to say, not everything that's not working as you'd expect at > first glance is broken by definition, this is just not a very good > collaborative approach :/ My expectations are based, in part, on having read through your code, including the comments. That's hardly "at first glance". If I still misunderstand things fundamentally, it's possible, even likely, that we need to add more documentation (and correct existing documentation) explaining, for example, that meta-variables introduced in an assume do not have a value and that their slot number is meaningless. Once we've done that, we can discuss why I think that would be a very bad design choice. Regards Pip