From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 20 19:13:45 2021 Received: (at submit) by debbugs.gnu.org; 21 Feb 2021 00:13:45 +0000 Received: from localhost ([127.0.0.1]:53144 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDcNd-0002EM-Dv for submit@debbugs.gnu.org; Sat, 20 Feb 2021 19:13:45 -0500 Received: from lists.gnu.org ([209.51.188.17]:40736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDcNZ-0002EC-Af for submit@debbugs.gnu.org; Sat, 20 Feb 2021 19:13:43 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60184) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDcNZ-000104-59 for bug-gnu-emacs@gnu.org; Sat, 20 Feb 2021 19:13:41 -0500 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:41573) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lDcNU-0002Cs-PL for bug-gnu-emacs@gnu.org; Sat, 20 Feb 2021 19:13:39 -0500 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id ABFFB5C00A7 for ; Sat, 20 Feb 2021 19:13:33 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sat, 20 Feb 2021 19:13:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=collares.org; h= from:to:subject:date:message-id:mime-version:content-type; s= fm2; bh=jK4AvCyUvjxffDF6tEYih5E1U/RNzatm+dNnKgUhAYk=; b=poOuv8Ud 8c/R7sl2Um54hWuz8i1DVeU5Rc0AyYDVgkQPxVLVlIptbXNV+5SDZ59geNGQfG7D DOzKuznu1sPkq1QrdOfDpPrZjMpJEGtR3KG1+fLk2xNOr0+9esa+jsBlZWnISIjd 4WIEqaDOo/pWKourdOgFkLp+YHLF4lqRKzphLpdnv/qNnT8lmgS2JSmWXAaZB8w/ Ep2z4p3geBfVTffvQeLrVb120djAPtf0KpjIPNYW0r5fU6IibH0IuVUxrj+FlHsV A8XeP1gQYqbd0VnHg9zPbGyrspJ0c9JTRya7oCsOm9FlzAW/OQEVLIQIuDilQvYk wh8JDNytHDo5Yg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=jK4AvCyUvjxffDF6tEYih5E1U/RNz atm+dNnKgUhAYk=; b=c4MLzNOURTy4ZffJRsf6RcFsujnGeV4/Etrrrt8G+UNof qWay4JRg9eYBXbXwDmfLv/soM3W9lb8Arx1oc/B1fPN7LmYlj3ZrVsnGd1UBN+45 KfUdspt7aTr1dnyx/vJa8LO7N2usyKktWXvcpnCLh0kaUyK4joAxlboEBM1RjAYF P4NPo90NrUg7YBOP5r6GipmRqEnVCiKZGn1i2NPHyso+jCkzm+6g4SIKkZ4kmBW7 3qYgOqv8BYvyYoin8QMEk6I76DNKmGyiSnLynUwdeuZuzFYIWUfTVb/8QF7aoxLt e+cO40fiyQtAB10ftUcQ1PNW7kuIO0EU/KBUI7lMA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrjeelgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfggtgesthdtredttddttd enucfhrhhomhepofgruhhrihgtihhoucevohhllhgrrhgvshcuoehmrghurhhitghiohes tgholhhlrghrvghsrdhorhhgqeenucggtffrrghtthgvrhhnpeevveevteeludetfeeuvd elffefueehtddtleffhffflefhhfeiudelveefieetgeenucfkphepudeluddrudekhedr feegrddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhgruhhrihgtihhosegtohhllhgrrhgvshdrohhrgh X-ME-Proxy: Received: from asus (unknown [191.185.34.215]) by mail.messagingengine.com (Postfix) with ESMTPA id A3F841080063 for ; Sat, 20 Feb 2021 19:13:32 -0500 (EST) From: Mauricio Collares To: bug-gnu-emacs@gnu.org Subject: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode Date: Sat, 20 Feb 2021 21:12:11 -0300 Message-ID: <87a6ry46uc.fsf@collares.org> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=66.111.4.29; envelope-from=mauricio@collares.org; helo=out5-smtp.messagingengine.com X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.6 (--) This was found by Anthony Cowley, who isolated the exact function in lsp-mode that was misbehaving. I verified that I could reproduce this findings, and then I removed surrounding context to obtain a minimized testcase. If this fails to reproduce, it's entirely my fault. Steps to reproduce: 1) Put this in minimized.el: ;;; -*- lexical-binding: t; -*- (defun minimized--look-back (s) (and (equal (buffer-substring-no-properties (- (point) (length s)) (point)) s) s)) (defun minimized-go () (interactive) (message (minimized--look-back "."))) (provide 'minimized) 2) Type "." in a buffer and then run minimized-go with the point after the period. This prints back "." in the minibuffer if the code's interpreted but not if it's native-compiled. Note that removing the "lexical-binding: t" line makes the bug not reproduce. Replacing "(- (point) (length s))" by "(1- (point))" also makes the bug disappear. Best, Mauricio From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 06:52:07 2021 Received: (at 46670) by debbugs.gnu.org; 21 Feb 2021 11:52:07 +0000 Received: from localhost ([127.0.0.1]:53619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDnHS-0004n9-Ry for submit@debbugs.gnu.org; Sun, 21 Feb 2021 06:52:07 -0500 Received: from mail-oi1-f173.google.com ([209.85.167.173]:38508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDnHQ-0004md-IA for 46670@debbugs.gnu.org; Sun, 21 Feb 2021 06:52:06 -0500 Received: by mail-oi1-f173.google.com with SMTP id h17so11161027oih.5 for <46670@debbugs.gnu.org>; Sun, 21 Feb 2021 03:52:04 -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=NhHpfM6+SwMHueDePuBPH3EE+SZPcyTfOMrMFX4xOOA=; b=q5muSwwhhyXlubJzsjuYRr3ICfYjTEmMMY4BomrjFeYFKWgFkLL7cRFIOJOzdCALrw In5mg75qJe+3WAS/KiY+DroiPhVzEBro5l3xfYUVXKPvjPjeSYfV5rbmdEm/72DheRTx h6CMLRz/ByjRv/jY2gBkdA9lHAFCGZ2z5BNZHUgvW/b4P/ehI4WXFHHbQriYwUTKJ17u AJhl2I9Gpu+QOOVRyqR3t7jjK38deR9zNWT2qs/yYy4HVAvoOCSsRUsEMl4P+XJg3DTd RIvX+6+QJAnCwVBtTIAUA3k3XT0V+qAG9t2h3DaraJoX1IY4K96PE9fwQlvmE298czfG g51A== 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=NhHpfM6+SwMHueDePuBPH3EE+SZPcyTfOMrMFX4xOOA=; b=aIoiHxft9T7FCYhjtYOL7K63xJJnbTjIKhRSmfIgiOOoKtohj/ndVb0J73lilG89eg //kaJCAuVC387tMg9oCf4xXYxYXDt4+0axRk8mYcYlqQ7mcllDVplD8xDQeN9bqxb9Ds ntK9H5sN45YcsAbaLP5ZQLzI5pncY9Cp3asgdzQfJt7UpqPx9NC0EZ4QBbBG5tWh/SOA ShzzoCqmBB2OVZYxvrZYmB+pFuV1b//bHe2Mz6HOhUazBmcWAhWRbb9w8IM4hWvMvNG2 DS6MCWniVMtkEkNY50oqwgH5LXjBBjokgv9sD4xyhSO3VNxd+M/D55W7L3L4hFg8XJav J80g== X-Gm-Message-State: AOAM533SAL9hyHM1BuToEA5srul6id9vQ92M+uK4UAbMSuedZcBFH2cm 1H4fz2uNFP60UH3+l7qIZiofm9ZuDBIqIiacMRdGA77y1Ns= X-Google-Smtp-Source: ABdhPJxDtDdk5oDZDK2uhqf6pdzwg7M8o8ZcObUUPz9itZ4NJnNbxxzK7zN9HKU7VDxcIWVZLH1OEvQkcKDACBA+t+A= X-Received: by 2002:aca:4c5:: with SMTP id 188mr8337309oie.44.1613908318817; Sun, 21 Feb 2021 03:51:58 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: <87a6ry46uc.fsf@collares.org> From: Pip Cet Date: Sun, 21 Feb 2021 11:51:22 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Mauricio Collares Content-Type: multipart/mixed; boundary="0000000000000b239405bbd750a7" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000000b239405bbd750a7 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 21, 2021 at 12:14 AM Mauricio Collares wrote: > This was found by Anthony Cowley, who isolated the exact function in > lsp-mode that was misbehaving. I verified that I could reproduce this > findings, and then I removed surrounding context to obtain a minimized > testcase. If this fails to reproduce, it's entirely my fault. > > Steps to reproduce: > > 1) Put this in minimized.el: > > ;;; -*- lexical-binding: t; -*- > > (defun minimized--look-back (s) > (and (equal (buffer-substring-no-properties (- (point) (length s)) (point)) > s) > s)) > > (defun minimized-go () > (interactive) > (message (minimized--look-back "."))) > > (provide 'minimized) > > 2) Type "." in a buffer and then run minimized-go with the point after > the period. This prints back "." in the minibuffer if the code's > interpreted but not if it's native-compiled. > > Note that removing the "lexical-binding: t" line makes the bug not > reproduce. Replacing "(- (point) (length s))" by "(1- (point))" also > makes the bug disappear. I can reproduce this with this code: (funcall (let ((comp-verbose 3) (comp-debug 3)) (native-compile `(lambda (s) (and (equal (buffer-substring-no-properties (- (point) (length s)) (point)) s) s)))) ")") I think there's some confusion in comp-fwprop-insn between (and) as a logical operator and (and) as a pcase operator. The latter means a variable's constraint must be in the intersection of all argument types, but the former only implies that the variable constraint is somewhere in the union of the argument constraints [1]. Does the attached patch help? Andrea, is my analysis correct? Pip [1] - note that we emit (assume a (and b c)) for (setq a (and c b)) under some circumstances, so it would be incorrect to use only c's constraint. --0000000000000b239405bbd750a7 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-native-comp-Fix-constraint-for-assume-x-and-a-b-Bug-.patch" Content-Disposition: attachment; filename="0001-native-comp-Fix-constraint-for-assume-x-and-a-b-Bug-.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_klf385i80 RnJvbSBiZDNhODIzYjgyN2M5Mzk0YzExYWFlNjNkYzNmYTgxMDk4Njk5Mjk2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBTdW4s IDIxIEZlYiAyMDIxIDExOjQ0OjI3ICswMDAwClN1YmplY3Q6IFtQQVRDSF0gW25hdGl2ZS1jb21w XSBGaXggY29uc3RyYWludCBmb3IgKGFzc3VtZSB4IChhbmQgYSBiKSkKIChCdWcjNDY2NzApCgoq IGxpc3AvZW1hY3MtbGlzcC9jb21wLmVsIChjb21wLWZ3cHJvcC1pbnNuKTogVXNlIGNvbXAtY3N0 ci11bmlvbiwgbm90CmNvbXAtY3N0ci1pbnRlcnNlY3Rpb24uCi0tLQogbGlzcC9lbWFjcy1saXNw L2NvbXAuZWwgfCAyICstCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRp b24oLSkKCmRpZmYgLS1naXQgYS9saXNwL2VtYWNzLWxpc3AvY29tcC5lbCBiL2xpc3AvZW1hY3Mt bGlzcC9jb21wLmVsCmluZGV4IDQwMzYwODA5NzY1NDYuLjk2NTEyMTY1N2Y2MDEgMTAwNjQ0Ci0t LSBhL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsCisrKyBiL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVs CkBAIC0zMDU5LDcgKzMwNTksNyBAQCBjb21wLWZ3cHJvcC1pbnNuCiAgICAgKGAoYXNzdW1lICxs dmFsICgsa2luZCAuICxvcGVyYW5kcykpCiAgICAgIChjbC1jYXNlIGtpbmQKICAgICAgICAoYW5k Ci0gICAgICAgIChhcHBseSAjJ2NvbXAtY3N0ci1pbnRlcnNlY3Rpb24gbHZhbCBvcGVyYW5kcykp CisgICAgICAgIChhcHBseSAjJ2NvbXAtY3N0ci11bmlvbiBsdmFsIG9wZXJhbmRzKSkKICAgICAg ICAobm90CiAgICAgICAgIDs7IFByZXZlbnQgZG91YmxlIG5lZ2F0aW9uIQogICAgICAgICAodW5s ZXNzIChjb21wLWNzdHItbmVnIChjYXIgb3BlcmFuZHMpKQotLSAKMi4zMC4wCgo= --0000000000000b239405bbd750a7-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 06:56:52 2021 Received: (at 46670) by debbugs.gnu.org; 21 Feb 2021 11:56:52 +0000 Received: from localhost ([127.0.0.1]:53623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDnM4-0004ua-H6 for submit@debbugs.gnu.org; Sun, 21 Feb 2021 06:56:52 -0500 Received: from mail-ot1-f41.google.com ([209.85.210.41]:43441) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDnM2-0004uN-Kw for 46670@debbugs.gnu.org; Sun, 21 Feb 2021 06:56:51 -0500 Received: by mail-ot1-f41.google.com with SMTP id l23so9464682otn.10 for <46670@debbugs.gnu.org>; Sun, 21 Feb 2021 03:56:50 -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=5wIgdgEFMfyUpdpNGZgYkzppJMj+va4TwbPwwsDZo5E=; b=OjabcS8pWo0DoJrf5O3KuhkTN4H+B+zR2fWqn8yFnqUj909UtxVTODRj6jsypn7rja keH0uPcffMxdEfYeVwj9Pekfx0hqKSSxfo9SiS8n7HkvIBXlmGDE8DLDespClX/SeRqR 02OvFn3s6fQEtLMJLQQeSrp9pFb9203a0XX7WeQopi7ta1k10Blq8x6AXv9y+h0e5o9N A3YspxrBH3LvGAZpDnbYw6oKQcoaiGC51Ta0PZTpp0tRCWac0x8GQpBSeSYrdeQdRidB ZZ5o9r2KyQ3HjoZ8sYgU1PvCVAER4Z9nvoc+ImZhZGn586KqvCN0Dlu0CC6mWfa2RZCW sovw== 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=5wIgdgEFMfyUpdpNGZgYkzppJMj+va4TwbPwwsDZo5E=; b=JY8Yj5H9K0gtv+oTjNO02INZRQy8ujVoU8IIcPEGwndZGLA6pN4Vniwr0JQueLmU4h ab765FDv9Ur+0PCAKx7N+e8ErkGozxUpz6unrgBBdzo3bDyIesSTL3C7WVZWLkdWAPbY 4AVjqU143OIwAVxYVhTFRv+4iGtq/VuTnr0qZIr8gqkjoxjAFHLgI6SZw/eF9V6Fzn4r Q4a3kXY/poHTSi7b41NQCPh23sXfraL+YDaxd5Meb4omhM1+M7d6yimlbMRltOAUlaYE C0DnAKjKvJjLRZ/GpndJCnYRlPKvGa56VzOlN9YWv0Z9vK3yaZO8xFyAGVm4fqqQzBrO o+8w== X-Gm-Message-State: AOAM530wMQbrRHQp7eGrjMvXfTHjXwclJZzWk4xcAzm03DqzDFlNEnHh ggfAHIAkk2OjRVAsE8ihXGb027xI5+9hcwI7jFU= X-Google-Smtp-Source: ABdhPJyEOOQE6C8Wyr2/0zSWwXBClrt84ybb09U3nVh8IKGaezCQxcqcDovjzI65bXkgQqJuRgSBrFcnPnJ7imvGPEI= X-Received: by 2002:a05:6830:1605:: with SMTP id g5mr13358485otr.292.1613908605025; Sun, 21 Feb 2021 03:56:45 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Sun, 21 Feb 2021 11:56:08 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Mauricio Collares Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sun, Feb 21, 2021 at 11:51 AM Pip Cet wrote: > Does the attached patch help? Andrea, is my analysis correct? CCing Andrea. In more detail, some debugging showed we were trying to intersect a "nil or t" constraint with a "sequence" constraint, the result being a null constraint (t is not a sequence). So if (assume (and a b)) was meant to imply the intersection of a and b, we're emitting it incorrectly. Pip From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 16:03:39 2021 Received: (at 46670) by debbugs.gnu.org; 21 Feb 2021 21:03:39 +0000 Received: from localhost ([127.0.0.1]:55029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDvtC-0000Gq-Lt for submit@debbugs.gnu.org; Sun, 21 Feb 2021 16:03:39 -0500 Received: from mx.sdf.org ([205.166.94.24]:51275) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDvtA-0000Ge-SU for 46670@debbugs.gnu.org; Sun, 21 Feb 2021 16:03:37 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11LL3SLc005583 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sun, 21 Feb 2021 21:03:30 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Sun, 21 Feb 2021 21:03:28 +0000 In-Reply-To: (Pip Cet's message of "Sun, 21 Feb 2021 11:56:08 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Sun, Feb 21, 2021 at 11:51 AM Pip Cet wrote: >> Does the attached patch help? Andrea, is my analysis correct? > > CCing Andrea. > > In more detail, some debugging showed we were trying to intersect a > "nil or t" constraint with a "sequence" constraint, the result being a > null constraint (t is not a sequence). So if (assume (and a b)) was > meant to imply the intersection of a and b, we're emitting it > incorrectly. Hi Pip, thanks for looking into this. 'and' is meant to imply intersection, so yeah... as you guess there's some problem in the LIMPLE we generate :) Just to mention we have also a number of tests in comp-tests.el to checks that we predict the correct return value, applying the suggested patch a number of these are not passing. We'll want to add also a new test there for this specific case when the issue is solved. Here a slightly more reduced test-case I'm using here for the analysis for which the compiler erroneously proves the return type is null. (let ((comp-verbose 3)) (native-compile '(=CE=BB (s) (and (equal (foo (length s)) s) s)))) Here is why, looking at LIMPLE coming in the final pass in bb_1 we emit: (assume #(mvar 41121096 0 null) (and #(mvar 42082902 0 sequence) #(mvar 411= 21566 1 boolean))) bb_1 is the basic block where 'equal' is verified so we want to enforce that the result cstr of the call 'foo' is intersected with 's' because they are equal. Now the trouble is that while 's' here is represented correctly by the mvar 42082902 the other operand of the and constraint is wrong. Where this is coming from then? Inside the predecessor block bb_0 we have the compare and branch sequence: (set #(mvar 41121566 1 boolean) (call equal #(mvar 42082358 1 t) #(mvar 416= 65638 2 sequence))) (cond-jump #(mvar 41121566 1 boolean) #(mvar nil nil null) bb_2_cstrs_0 bb_= 1) Here when we run the 'add-cstrs' pass `comp-add-cond-cstrs' is deciding that 42082358 41665638 must be constrained and therefore is emitting the assume. Unfortunatelly because 42082358 and 41121566 are sharing the same slot number when we do the next SSA rename the mvar referenced in the assume will be one that is produced by 'equal' and not the one that is consumed. The correct fix is to have `comp-add-cond-cstrs' rewrite the comparison sequence as something like: (set #(mvar nil X t) #(mvar 42082358 1 t)) (set #(mvar 41121566 1 boolean) (call equal #(mvar 42082358 1 t) #(mvar 416= 65638 2 sequence))) (cond-jump #(mvar 41121566 1 boolean) #(mvar nil nil null) bb_2_cstrs_0 bb_= 1) Where X is a new slot we add to the frame. We will reference this slot number in the assume instead of 1 so it does not get clobbered. Now I'm not 100% sure how trivial is to do that as no pass is ATM changing the frame size. I guess I'll try to write a patch tomorrow evening. Thanks! Andrea From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 21 17:47:13 2021 Received: (at 46670) by debbugs.gnu.org; 21 Feb 2021 22:47:14 +0000 Received: from localhost ([127.0.0.1]:55161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDxVR-0004sU-L8 for submit@debbugs.gnu.org; Sun, 21 Feb 2021 17:47:13 -0500 Received: from mail-oi1-f169.google.com ([209.85.167.169]:36203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lDxVP-0004s2-3w for 46670@debbugs.gnu.org; Sun, 21 Feb 2021 17:47:12 -0500 Received: by mail-oi1-f169.google.com with SMTP id j1so240912oiw.3 for <46670@debbugs.gnu.org>; Sun, 21 Feb 2021 14:47:11 -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=3Yj/+BkcU6rRAQAcgNs2EB/7aIpf6iCgGi6dl3wLwVg=; b=diAT+L9Zv+bxFk86OArJHuZ/7UVWuMJhgZFnk2erb0oio/4Ugfqg//84Ao3ntPjJ39 21V6DmP0cIKwkuDG0P7j88xmpLElnaErUW6EfQHOvRdUW/YWWvEUG6G+6N2t63BI0sY4 8iz1LM59RDaRCBiEVSnsP56wXYjdJXdYMemEAGetNEhVZzV8kgeIFxE2kI6YZMTWiCun h3HJ0Dgflydd1O4qBLS3LQcODVuOABYwIfTj/Ds8YWfb9w+tnhAFEF98Gbl8snjd3B5f ET0o52sYzwPxyPbt2Gf5yxuBmgXFig0cKveYu89S7nZ6hJefs5mot36lOIjmdflzjYd2 ydDg== 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=3Yj/+BkcU6rRAQAcgNs2EB/7aIpf6iCgGi6dl3wLwVg=; b=p861rR7YFsNN8EqkK02ZVBdg3LJ4UwwDblBRgXfcmRFsjq/ci9FJYQY/GzQ2TPHLSH ueNDgvfZzqooKAGqmOw/41rMHNddC4XVY+gAa9NdAQTzyTGE5H/UhQUxOu1pveknhWoR LLzbUwieRE5PC0OAxNT5EGcZl0H+fODnuGkjY93OpXfJ3gQxaXws/g8vXSB1LabLf/tq Q3+XyfY/vuzwJ9GJscjeaZ54wFYPvpmXj9xiWChVGTaUJvIQlrBLXyJjF6N7wUCFc3Lo OygGlsm4ZJOFc9XNa8aLu7tWofL+6zIKxcedIQSLTm7BvXTa73UD8b40RKiV2b434+ux pgMg== X-Gm-Message-State: AOAM531YKsBK0JKrfG0aPiJKvqKmoGeyfwL0AbX3XNZBxTo02aNZ0dOk NSQz+zzvDWxa6regbMJza2iCDiS/os14ng8NY3s= X-Google-Smtp-Source: ABdhPJzPxU/TZEyf+rYmLQ0bjAlArVt00+SsmJjToNNxscriLMKWbUcSvTCndYGLQKusFo20w97AQnVGS/e9+AH2Mj8= X-Received: by 2002:aca:6141:: with SMTP id v62mr13514534oib.30.1613947625308; Sun, 21 Feb 2021 14:47:05 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Sun, 21 Feb 2021 22:46:29 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: multipart/mixed; boundary="000000000000e49a8905bbe0761c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000e49a8905bbe0761c Content-Type: text/plain; charset="UTF-8" On Sun, Feb 21, 2021 at 9:03 PM Andrea Corallo wrote: > Pip Cet writes: > > > On Sun, Feb 21, 2021 at 11:51 AM Pip Cet wrote: > >> Does the attached patch help? Andrea, is my analysis correct? > > > > CCing Andrea. > > > > In more detail, some debugging showed we were trying to intersect a > > "nil or t" constraint with a "sequence" constraint, the result being a > > null constraint (t is not a sequence). So if (assume (and a b)) was > > meant to imply the intersection of a and b, we're emitting it > > incorrectly. > > Hi Pip, > > thanks for looking into this. Thanks for your explanation! > 'and' is meant to imply intersection, so yeah... as you guess there's > some problem in the LIMPLE we generate :) Thanks, I was on the wrong track there. > The correct fix is to have `comp-add-cond-cstrs' rewrite the comparison > sequence as something like: > > (set #(mvar nil X t) #(mvar 42082358 1 t)) > (set #(mvar 41121566 1 boolean) (call equal #(mvar 42082358 1 t) #(mvar 41665638 2 sequence))) > (cond-jump #(mvar 41121566 1 boolean) #(mvar nil nil null) bb_2_cstrs_0 bb_1) > > Where X is a new slot we add to the frame. We will reference this slot > number in the assume instead of 1 so it does not get clobbered. Okay, I think I understand the problem (we don't do classical SSA and throw away the slot numbers), and your solution would avoid it, but it seems needlessly complicated to me. Why create a new slot that isn't used anywhere? The value of the stack slot is clobbered by the (set ...), so we cannot emit any assumptions about that stack slot based on previous values it held. In fact, all we need to do is tell comp-cond-cstrs-target-mvar to return nil more often, isn't it? Pip --000000000000e49a8905bbe0761c Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Don-t-lie-about-who-set-the-variable.patch" Content-Disposition: attachment; filename="0001-Don-t-lie-about-who-set-the-variable.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_klfqnon80 RnJvbSAyYTQwMDQ5MDg1MWM1MzBiZDUxZjhhNDQ1M2QwZDNmYjQ1MmFiNTYxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBTdW4s IDIxIEZlYiAyMDIxIDIyOjQwOjA1ICswMDAwClN1YmplY3Q6IFtQQVRDSF0gRG9uJ3QgbGllIGFi b3V0IHdobyBzZXQgdGhlIHZhcmlhYmxlLgoKLS0tCiBsaXNwL2VtYWNzLWxpc3AvY29tcC5lbCB8 IDQgKystLQogMSBmaWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkK CmRpZmYgLS1naXQgYS9saXNwL2VtYWNzLWxpc3AvY29tcC5lbCBiL2xpc3AvZW1hY3MtbGlzcC9j b21wLmVsCmluZGV4IDQwMzYwODA5NzY1NDYuLjE5NGIxNTEyY2MyYzQgMTAwNjQ0Ci0tLSBhL2xp c3AvZW1hY3MtbGlzcC9jb21wLmVsCisrKyBiL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsCkBAIC0y MzE3LDExICsyMzE3LDExIEBAIGNvbXAtY29uZC1jc3Rycy10YXJnZXQtbXZhcgogICAgIChjbC1s b29wCiAgICAgIHdpdGggcmVzID0gbmlsCiAgICAgIGZvciBpbnNuIGluIChjb21wLWJsb2NrLWlu c25zIGJiKQotICAgICB3aGVuIChlcSBpbnNuIGV4aXQtaW5zbikKLSAgICAgZG8gKGNsLXJldHVy biAoYW5kIChjb21wLW12YXItcCByZXMpIHJlcykpCiAgICAgIGRvIChwY2FzZSBpbnNuCiAgICAg ICAgICAgKGAoLChwcmVkIGNvbXAtYXNzaWduLW9wLXApICwocHJlZCB0YXJnZXRwKSAscmhzKQog ICAgICAgICAgICAoc2V0ZiByZXMgcmhzKSkpCisgICAgIHdoZW4gKGVxIGluc24gZXhpdC1pbnNu KQorICAgICBkbyAoY2wtcmV0dXJuIChhbmQgKGNvbXAtbXZhci1wIHJlcykgcmVzKSkKICAgICAg ZmluYWxseSAoY2wtYXNzZXJ0IG5pbCkpKSkKIAogKGRlZnVuIGNvbXAtYWRkLWNvbmQtY3N0cnMt dGFyZ2V0LWJsb2NrIChjdXJyLWJiIHRhcmdldC1iYi1zeW0pCi0tIAoyLjMwLjAKCg== --000000000000e49a8905bbe0761c-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 04:38:07 2021 Received: (at 46670) by debbugs.gnu.org; 22 Feb 2021 09:38:07 +0000 Received: from localhost ([127.0.0.1]:55655 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE7fL-0005rh-Da for submit@debbugs.gnu.org; Mon, 22 Feb 2021 04:38:07 -0500 Received: from mx.sdf.org ([205.166.94.24]:54874) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE7fG-0005rF-Ek for 46670@debbugs.gnu.org; Mon, 22 Feb 2021 04:38:06 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11M9btdX006574 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 22 Feb 2021 09:37:57 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Mon, 22 Feb 2021 09:37:55 +0000 In-Reply-To: (Pip Cet's message of "Sun, 21 Feb 2021 22:46:29 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Sun, Feb 21, 2021 at 9:03 PM Andrea Corallo wrote: >> Pip Cet writes: >> >> > On Sun, Feb 21, 2021 at 11:51 AM Pip Cet wrote: >> >> Does the attached patch help? Andrea, is my analysis correct? >> > >> > CCing Andrea. >> > >> > In more detail, some debugging showed we were trying to intersect a >> > "nil or t" constraint with a "sequence" constraint, the result being a >> > null constraint (t is not a sequence). So if (assume (and a b)) was >> > meant to imply the intersection of a and b, we're emitting it >> > incorrectly. >> >> Hi Pip, >> >> thanks for looking into this. > > Thanks for your explanation! > >> 'and' is meant to imply intersection, so yeah... as you guess there's >> some problem in the LIMPLE we generate :) > > Thanks, I was on the wrong track there. > >> The correct fix is to have `comp-add-cond-cstrs' rewrite the comparison >> sequence as something like: >> >> (set #(mvar nil X t) #(mvar 42082358 1 t)) >> (set #(mvar 41121566 1 boolean) (call equal #(mvar 42082358 1 t) #(mvar 41665638 2 sequence))) >> (cond-jump #(mvar 41121566 1 boolean) #(mvar nil nil null) bb_2_cstrs_0 bb_1) >> >> Where X is a new slot we add to the frame. We will reference this slot >> number in the assume instead of 1 so it does not get clobbered. > > Okay, I think I understand the problem (we don't do classical SSA and > throw away the slot numbers), and your solution would avoid it, but it > seems needlessly complicated to me. Correct, ATM the assumption is that we keep LIMPLE always as "conventional SSA form". This for a number of reasons but mainly it greatly helps in maintaining the compiler simple. I've experimented investing quite some effort into removing this assumption but the result was definitely more complex and the produced code considerably harder to debug. The only advantage I could see in the end was having a simpler and more elegant `comp-cond-cstrs-target-mvar' due to the fact that was trivial to implement a copy propagation pass), so I deemed was a good move to keep always the conventional form. > Why create a new slot that isn't used anywhere? The value of the stack > slot is clobbered by the (set ...), so we cannot emit any assumptions > about that stack slot based on previous values it held. Yes but in this case (and probably others) we *have* to emit this assumption. The best option is to decide that negative slot numbers are not rendered into libgccjit IR and we consider these virtual to solve these kind of cases. IIRC we already do something similar for the -1 index so this concept has just to be generalized a bit. > In fact, all we need to do is tell comp-cond-cstrs-target-mvar to > return nil more often, isn't it? Nope, the target mvar identified is the correct one, we just have ATM no way to reference it reliably into the assume. BTW applying your patch is breaking quite some of the comp-tests-ret-type-spec-* tests :) Andrea From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 05:05:24 2021 Received: (at 46670) by debbugs.gnu.org; 22 Feb 2021 10:05:24 +0000 Received: from localhost ([127.0.0.1]:55693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE85k-0006XE-8m for submit@debbugs.gnu.org; Mon, 22 Feb 2021 05:05:24 -0500 Received: from mail-ot1-f42.google.com ([209.85.210.42]:40560) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE85i-0006Wo-QT for 46670@debbugs.gnu.org; Mon, 22 Feb 2021 05:05:23 -0500 Received: by mail-ot1-f42.google.com with SMTP id b8so11418141oti.7 for <46670@debbugs.gnu.org>; Mon, 22 Feb 2021 02:05:22 -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=AFyySltaa8V9tju+y0URnlEXavXIT/655dGGhNpum2I=; b=C/lGt+/wc0FQzr+rvl0vu3h8+jcIEry+YLmlYnCL9qH07lazXQkIb2VPnXeLhORhcS ALqKEKoQb8kPmH01I0bNJsnPVJWWxkjeZc2BchcUfMl26JQ3gmj3BPU5i4SJgAmIpxJ7 0lSDy5ekx2xMXSrfwjPvhvZX0nsAO63t3v0J0R1IEKKea4IyQ5xXWov7E76jzIaR5c0a f5VLT8Gd+4PDzxlenJJjIokso16yn1MKDyrZnY1PcauzAbZsS7XGSqOWU2ijmIjAIc8S OEfDV9wOz1VjWXpiwQcgWNbBkvNWswG/KNfV7a3F0v1uPXu5oKg9o9429acSZX2fQ56y T9aA== 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=AFyySltaa8V9tju+y0URnlEXavXIT/655dGGhNpum2I=; b=NeffvxUfKRB2sD/Ci0+VcQnanB2DDKw6ZkEE9hUILJny6mN0HnBDxsP/F02vpU6MDO hpgfpKumW+lqBZQK4gJbJNViRznuGbpnmSiq7TnEKmzoC33fqRHRPD0t4JtiAmcIsrf2 LsUcH8OCfBAb+4AJJPEEbc83TS9KN2H1LDIlzKohyicakRCiqjHndAca8qtAhZc6BE/W vSCmlgkdQHjQvhQAJPXIjDHfBzt2Qw+D59LjzINzv/992seCXzlVUKaIEdCAyt1OlR+a nSJjRe5uE1zoG/rRxpsdt9vcqeY5dChsQT7oct8IEGE+Wafsgpa/QtIw3r0nujA8K2Ty QJ7g== X-Gm-Message-State: AOAM533JDmqXZiBcblADihVo67XRX+Kf/2cvNySKSZyX/bwnvXzLLmqr FQ2j2IErod2yng64/9OwXHqTbNZqxfZJCx2VZJVe6z1q X-Google-Smtp-Source: ABdhPJyMEtMS6JwrOOzvrwmpXlFYyKoQ/dUqCGBnVzXIOlZCBg2Q/AuckvOnmO1Llq68Q87o7Y0Tb4FGud4fzxdgc94= X-Received: by 2002:a05:6830:1682:: with SMTP id k2mr16042112otr.154.1613988317192; Mon, 22 Feb 2021 02:05:17 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Mon, 22 Feb 2021 10:04:41 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Feb 22, 2021 at 9:38 AM Andrea Corallo wrote: > Pip Cet writes: > > On Sun, Feb 21, 2021 at 9:03 PM Andrea Corallo wrote: > >> Pip Cet writes: > >> > >> > On Sun, Feb 21, 2021 at 11:51 AM Pip Cet wrote: > >> >> Does the attached patch help? Andrea, is my analysis correct? > >> > > >> > CCing Andrea. > >> > > >> > In more detail, some debugging showed we were trying to intersect a > >> > "nil or t" constraint with a "sequence" constraint, the result being a > >> > null constraint (t is not a sequence). So if (assume (and a b)) was > >> > meant to imply the intersection of a and b, we're emitting it > >> > incorrectly. > >> > >> Hi Pip, > >> > >> thanks for looking into this. > > > > Thanks for your explanation! > > > >> 'and' is meant to imply intersection, so yeah... as you guess there's > >> some problem in the LIMPLE we generate :) > > > > Thanks, I was on the wrong track there. > > > >> The correct fix is to have `comp-add-cond-cstrs' rewrite the comparison > >> sequence as something like: > >> > >> (set #(mvar nil X t) #(mvar 42082358 1 t)) > >> (set #(mvar 41121566 1 boolean) (call equal #(mvar 42082358 1 t) #(mvar 41665638 2 sequence))) > >> (cond-jump #(mvar 41121566 1 boolean) #(mvar nil nil null) bb_2_cstrs_0 bb_1) > >> > >> Where X is a new slot we add to the frame. We will reference this slot > >> number in the assume instead of 1 so it does not get clobbered. > > > > Okay, I think I understand the problem (we don't do classical SSA and > > throw away the slot numbers), and your solution would avoid it, but it > > seems needlessly complicated to me. > > Correct, ATM the assumption is that we keep LIMPLE always as > "conventional SSA form". This for a number of reasons but mainly it > greatly helps in maintaining the compiler simple. "Conventional" meaning "not quite SSA"? I'm just trying to understand, the decision seems correct to me, since we already ran stack slot allocation in the byte compiler and we want to reuse those assignments. > > Why create a new slot that isn't used anywhere? The value of the stack > > slot is clobbered by the (set ...), so we cannot emit any assumptions > > about that stack slot based on previous values it held. > > Yes but in this case (and probably others) we *have* to emit this > assumption. Why? Are you saying the compiler requires (assume ...) insns for correctness? If it does, I'm afraid that's a serious issue. > The best option is to decide that negative slot numbers are not rendered > into libgccjit IR and we consider these virtual to solve these kind of > cases. IIRC we already do something similar for the -1 index so this > concept has just to be generalized a bit. Again, that does seem very complicated, and if it improves optimization we could probably improve it much more by modifying the byte compiler to pop arguments in the caller rather than the callee. > > In fact, all we need to do is tell comp-cond-cstrs-target-mvar to > > return nil more often, isn't it? > > Nope, the target mvar identified is the correct one, we just have ATM no > way to reference it reliably into the assume. We don't have to, let's just not emit an assume about a variable that we just introduced and that's never read? > BTW applying your patch > is breaking quite some of the comp-tests-ret-type-spec-* tests :) Where do you keep those? I see the same number of test failures with and without the patch, running "make check". The failures seem unrelated, too... From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 05:26:11 2021 Received: (at 46670) by debbugs.gnu.org; 22 Feb 2021 10:26:11 +0000 Received: from localhost ([127.0.0.1]:55731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE8Pr-000754-Ik for submit@debbugs.gnu.org; Mon, 22 Feb 2021 05:26:11 -0500 Received: from mail-ot1-f43.google.com ([209.85.210.43]:44919) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE8Pp-00074q-Uo for 46670@debbugs.gnu.org; Mon, 22 Feb 2021 05:26:10 -0500 Received: by mail-ot1-f43.google.com with SMTP id g6so7322738otk.11 for <46670@debbugs.gnu.org>; Mon, 22 Feb 2021 02:26:09 -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=9nVSsOge1PcqEd8ql0FncILvd9oaI1/TEqgb7wX0uf4=; b=DHhisInqivIRXd3qvx6AixFUcQ4S2aZdEqz1Cp3RPrYd93N7EVDoxTkfjJ9tYRFGh5 o8nSarlgB0XHf5ESycHsM5gGiovleMtRuxHWrvh2nnuiyyn4OqHCI8WFpFKKn7p9T7f4 IZoNv1IxYsAwkYsrGCMeqkzjcHjwqAuA7n5TIC/r11tu6bf9OckKnx1A5pVzsJcUNgEw f7WMr/f5booQBr+aah6VD95kyH8WadD1T8xrzKs2No7HLmJhwf9aDB300C907bccVBBB w0AIWTEZbCH6nnSQqPTR92WhdlWdlJbzWsB7w1ia9XQTUeBtYmyyL4BvH+C/gQ5eWiVB B6jQ== 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=9nVSsOge1PcqEd8ql0FncILvd9oaI1/TEqgb7wX0uf4=; b=mKdbIuky1gNLNNniY8APMou26lIIOogpTuws+ooIUYIo0Sr0UtPjJDQ7FdKXjnwGtQ BaCjJM3z2zo8kWf7bq4JnzJ38FSytgVC4HEZEooWRt4K20GKEHTY2sos8m90IU6nmluo DdOox2/JIcBtbIPuu11NLdgaRG3a8KGXtgrov5p7iW2S1rd9JieA1a0A0OMWCdmw3IYd K8oU86s2RNWmJ+FXxkvOChd4pEZn9c65BXx9PpDmZyI+KyUXWLpr665SKs1By/HJwylo +Nk94xBu4RZO79YU0qYG9xC+Cfg72IGuf/fR9AoIyx/uABRladtBrHm8pReYHI9W0D8w mrZg== X-Gm-Message-State: AOAM531bUjqsAv162SWubzfKnKb2z2GMnYJRIKtRevog17noOgBWH6/K 2OFhk8QNE/4w1gL+tdZctlBY5n9i000og0n9XOY= X-Google-Smtp-Source: ABdhPJzAMwEOb3pACNWEZ+v4wGaT6d8FMVs6kFDnPop/yRv+UsrO5Ug/s9LpnJ8iYusXkD2yB+BY5twbibm2+w9AEd8= X-Received: by 2002:a05:6830:1605:: with SMTP id g5mr16139896otr.292.1613989564260; Mon, 22 Feb 2021 02:26:04 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Mon, 22 Feb 2021 10:25:28 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Feb 22, 2021 at 10:04 AM Pip Cet wrote: > > BTW applying your patch > > is breaking quite some of the comp-tests-ret-type-spec-* tests :) > > Where do you keep those? Oh, I see, they're written as though they tested comp.c. At a quick glance, the test results aren't actually incorrect, they're merely missed optimizations. (Except for this one: ((defun comp-tests-ret-type-spec-f (x) (unless (symbolp x) x)) (not symbol)) If I'm reading that correctly, it tests that (unless (symbolp x) x) isn't a symbol, which it usually is) From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 06:16:47 2021 Received: (at 46670) by debbugs.gnu.org; 22 Feb 2021 11:16:47 +0000 Received: from localhost ([127.0.0.1]:55804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE9Co-0008Jh-Ob for submit@debbugs.gnu.org; Mon, 22 Feb 2021 06:16:47 -0500 Received: from mx.sdf.org ([205.166.94.24]:50901) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE9Cl-0008JV-MV for 46670@debbugs.gnu.org; Mon, 22 Feb 2021 06:16:45 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11MBGbGL004546 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 22 Feb 2021 11:16:38 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Mon, 22 Feb 2021 11:16:37 +0000 In-Reply-To: (Pip Cet's message of "Mon, 22 Feb 2021 10:04:41 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Mon, Feb 22, 2021 at 9:38 AM Andrea Corallo wrote: >> Pip Cet writes: >> > On Sun, Feb 21, 2021 at 9:03 PM Andrea Corallo wrote: >> >> Pip Cet writes: >> >> >> >> > On Sun, Feb 21, 2021 at 11:51 AM Pip Cet wrote: >> >> >> Does the attached patch help? Andrea, is my analysis correct? >> >> > >> >> > CCing Andrea. >> >> > >> >> > In more detail, some debugging showed we were trying to intersect a >> >> > "nil or t" constraint with a "sequence" constraint, the result being a >> >> > null constraint (t is not a sequence). So if (assume (and a b)) was >> >> > meant to imply the intersection of a and b, we're emitting it >> >> > incorrectly. >> >> >> >> Hi Pip, >> >> >> >> thanks for looking into this. >> > >> > Thanks for your explanation! >> > >> >> 'and' is meant to imply intersection, so yeah... as you guess there's >> >> some problem in the LIMPLE we generate :) >> > >> > Thanks, I was on the wrong track there. >> > >> >> The correct fix is to have `comp-add-cond-cstrs' rewrite the comparison >> >> sequence as something like: >> >> >> >> (set #(mvar nil X t) #(mvar 42082358 1 t)) >> >> (set #(mvar 41121566 1 boolean) (call equal #(mvar 42082358 1 t) #(mvar 41665638 2 sequence))) >> >> (cond-jump #(mvar 41121566 1 boolean) #(mvar nil nil null) bb_2_cstrs_0 bb_1) >> >> >> >> Where X is a new slot we add to the frame. We will reference this slot >> >> number in the assume instead of 1 so it does not get clobbered. >> > >> > Okay, I think I understand the problem (we don't do classical SSA and >> > throw away the slot numbers), and your solution would avoid it, but it >> > seems needlessly complicated to me. >> >> Correct, ATM the assumption is that we keep LIMPLE always as >> "conventional SSA form". This for a number of reasons but mainly it >> greatly helps in maintaining the compiler simple. > > "Conventional" meaning "not quite SSA"? I'm just trying to understand, > the decision seems correct to me, since we already ran stack slot > allocation in the byte compiler and we want to reuse those > assignments. The SSA book [1] and others discuss conventional and transformed SSA forms. IIRC you should find references of these in 2.5 and where copy propagation is discussed. >> > Why create a new slot that isn't used anywhere? The value of the stack >> > slot is clobbered by the (set ...), so we cannot emit any assumptions >> > about that stack slot based on previous values it held. >> >> Yes but in this case (and probably others) we *have* to emit this >> assumption. > > Why? Are you saying the compiler requires (assume ...) insns for > correctness? If it does, I'm afraid that's a serious issue. It requires that assume if we want to infer precisely here. If we give-up emitting this assume it will just works perfectly but we'll miss to predict the return value as we should. >> The best option is to decide that negative slot numbers are not rendered >> into libgccjit IR and we consider these virtual to solve these kind of >> cases. IIRC we already do something similar for the -1 index so this >> concept has just to be generalized a bit. > > Again, that does seem very complicated, and if it improves > optimization we could probably improve it much more by modifying the > byte compiler to pop arguments in the caller rather than the callee. To me this sounds considerably more invasive, probably is because I'm much more used to work with the native compiler code that with the byte compiler one :) I like the idea of the native compiler patch being less invasive as possible, this was the line I tried to follow and I think so far it paid. I guess a number of readers would'd agree with this kind of approach to begin with. I think I should be able to work it out as discussed in one two evenings and it might be useful for other cases in the future too, so it does not sound as a big deal to me. >> > In fact, all we need to do is tell comp-cond-cstrs-target-mvar to >> > return nil more often, isn't it? >> >> Nope, the target mvar identified is the correct one, we just have ATM no >> way to reference it reliably into the assume. > > We don't have to, let's just not emit an assume about a variable that > we just introduced and that's never read? We disagree :) We don't need that mvar to render functional code that's agreed, but still we still need to reference it in the assume (assumes are not functional code as they are not rendered in final). As the byte compiler does not care about propagating types and values it can just clobber the variable, here we aim for more so we need it to keep it live till the assume. >> BTW applying your patch >> is breaking quite some of the comp-tests-ret-type-spec-* tests :) > > Where do you keep those? > > I see the same number of test failures with and without the patch, > running "make check". The failures seem unrelated, too... They are in "test/src/comp-tests.el", those are the first I suggest to run after having modified the compiler. Isn't "make check" picking-up those? Regards Andrea [1] From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 06:23:56 2021 Received: (at 46670) by debbugs.gnu.org; 22 Feb 2021 11:23:56 +0000 Received: from localhost ([127.0.0.1]:55830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE9Jk-0008Vi-7E for submit@debbugs.gnu.org; Mon, 22 Feb 2021 06:23:56 -0500 Received: from mx.sdf.org ([205.166.94.24]:50408) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lE9Ji-0008Va-C9 for 46670@debbugs.gnu.org; Mon, 22 Feb 2021 06:23:54 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11MBNnHb013880 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 22 Feb 2021 11:23:50 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Mon, 22 Feb 2021 11:23:49 +0000 In-Reply-To: (Pip Cet's message of "Mon, 22 Feb 2021 10:25:28 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Mon, Feb 22, 2021 at 10:04 AM Pip Cet wrote: > >> > BTW applying your patch >> > is breaking quite some of the comp-tests-ret-type-spec-* tests :) >> >> Where do you keep those? > > Oh, I see, they're written as though they tested comp.c. > > At a quick glance, the test results aren't actually incorrect, they're > merely missed optimizations. Correct, note these is not only about potentially missed optimizations, we expose the derived return type with `subr-type' and in the future we might give it even more visibility (like using it it in the C-h f output). > (Except for this one: > > ((defun comp-tests-ret-type-spec-f (x) > (unless (symbolp x) > x)) > (not symbol)) > > If I'm reading that correctly, it tests that (unless (symbolp x) x) > isn't a symbol, which it usually is) Yep, it verifies that this function has as inferred return type (not symbol). Andrea From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 07:12:43 2021 Received: (at 46670) by debbugs.gnu.org; 22 Feb 2021 12:12:43 +0000 Received: from localhost ([127.0.0.1]:55980 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEA4x-0003Wx-BN for submit@debbugs.gnu.org; Mon, 22 Feb 2021 07:12:43 -0500 Received: from mail-ot1-f42.google.com ([209.85.210.42]:44120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEA4v-0003Wk-DQ for 46670@debbugs.gnu.org; Mon, 22 Feb 2021 07:12:41 -0500 Received: by mail-ot1-f42.google.com with SMTP id g6so7564007otk.11 for <46670@debbugs.gnu.org>; Mon, 22 Feb 2021 04:12:41 -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=D6tCvUZpNBYdNdm0ONY++b+CMTYjmDvGHb+2/CTW32Y=; b=h8tq/pOalhiC9M/dFpJ1Gf0kZ55zIowghT5/pApBhsaAoCLvamtHFe0S5zF+fD3tL1 fIOxE8UKqYFgTlUqSLZ/mGO9Z1sXjc9/FNvqI7CzKlG7Q+u9QS9r2So5rlp3pyuspGKx r3WXdTx1yG+Qp1h+gwIP03L9uH6WrmzofwbIRsLZI9Ge6NVojYFcEIJF4J40Fb8d0N8I 41u2VsEdmlLRmuudKqVgSMZEem9fKCH40GGgj//NJcY2HanSQcYk0xlZ0CdKVsIxyMmg T4oqB3nL028IXW3EpXMD7j1VMY7jwso6Y4birsDlBpTHSYWtWXX4RuLVXYCALzbby56G o/IA== 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=D6tCvUZpNBYdNdm0ONY++b+CMTYjmDvGHb+2/CTW32Y=; b=W9EP3dITYK8WjAWBYCat9yE2HdOm84i7V2aReUe6uoICFJ/lmyEczgyLj0m3IlqhxM LuY0eimQoyeRx1AsLt2LzvFt/poA2kRlMOZeXuTi9dTM9gNqmomMWTVUvtCphX0X8BBp dVyAReBK+eWxFmtE/A5tmGQlnWkCOo6FhJMoszkEs6nQOfAdzyTR7YiC6B/tHeElWn3F H/HBZI6wyELkIpA52FzHal+Hf0e/UQG0M9hjnVWGpAXPoGA5j8DOP9B4TnweLTmxDosi LWQQ5zenZ/QaIpIzK+BZy6NcfvZKppd9BRyoVnZeuAFZsatdC+ODD7rIimoPDa1x0Rf6 7weQ== X-Gm-Message-State: AOAM533rLLuttlIxIXyOV0y/pXve/8wd78SwFhKOvAFmOBnbPSQWEwJ+ DWwXsvNcggzCRhQ1nrlDlW7cJTdDI8AeiOEPN7w= X-Google-Smtp-Source: ABdhPJzhtmF4351XIiCEbBp6V9lwNKNKY75KqhKxhpTrd57ram0ohS394veMlRJE11ggBaP3VseThZQ+en4bexDNw18= X-Received: by 2002:a05:6830:249a:: with SMTP id u26mr11280444ots.287.1613995955795; Mon, 22 Feb 2021 04:12:35 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Mon, 22 Feb 2021 12:11:59 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Feb 22, 2021 at 11:23 AM Andrea Corallo wrote: > Pip Cet writes: > > On Mon, Feb 22, 2021 at 10:04 AM Pip Cet wrote: > > (Except for this one: > > > > ((defun comp-tests-ret-type-spec-f (x) > > (unless (symbolp x) > > x)) > > (not symbol)) > > > > If I'm reading that correctly, it tests that (unless (symbolp x) x) > > isn't a symbol, which it usually is) > > Yep, it verifies that this function has as inferred return type (not > symbol). Which means the return value shouldn't ever be a symbol, right? Because it's nil, which is a symbol, when (symbolp x). Am I missing something here? From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 22 08:12:45 2021 Received: (at 46670) by debbugs.gnu.org; 22 Feb 2021 13:12:45 +0000 Received: from localhost ([127.0.0.1]:56007 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEB12-00074D-Qd for submit@debbugs.gnu.org; Mon, 22 Feb 2021 08:12:45 -0500 Received: from mx.sdf.org ([205.166.94.24]:59186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEB0z-000744-TB for 46670@debbugs.gnu.org; Mon, 22 Feb 2021 08:12:43 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11MDCaV9005827 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 22 Feb 2021 13:12:36 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Mon, 22 Feb 2021 13:12:36 +0000 In-Reply-To: (Pip Cet's message of "Mon, 22 Feb 2021 12:11:59 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Mon, Feb 22, 2021 at 11:23 AM Andrea Corallo wrote: >> Pip Cet writes: >> > On Mon, Feb 22, 2021 at 10:04 AM Pip Cet wrote: >> > (Except for this one: >> > >> > ((defun comp-tests-ret-type-spec-f (x) >> > (unless (symbolp x) >> > x)) >> > (not symbol)) >> > >> > If I'm reading that correctly, it tests that (unless (symbolp x) x) >> > isn't a symbol, which it usually is) >> >> Yep, it verifies that this function has as inferred return type (not >> symbol). > > Which means the return value shouldn't ever be a symbol, right? > Because it's nil, which is a symbol, when (symbolp x). Am I missing > something here? Sorry I though the question was on the test mechanism and wasn't pay attention to the specific testcase content :/ Right that's clearly a bug in `comp-cstr-union-1-no-mem' that was missing to check that no negative type is shadowing any positive type coming from values and giving-up returning t in case). Good catch thanks! :) Should be fixed by d6227f6edc. Andrea PS as I see you are interested into this part of the compiler, I find typically handy to exercise this logic with like: (let ((comp-ctxt (make-comp-cstr-ctxt))) (comp-cstr-to-type-spec (comp-type-spec-to-cstr '(or (not symbol) null)))) We'll probably see other bugs in this area cause is tricky, is important we build the best coverage we can for this in the testsuite. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 03:00:18 2021 Received: (at 46670) by debbugs.gnu.org; 23 Feb 2021 08:00:18 +0000 Received: from localhost ([127.0.0.1]:58211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEScD-0001Zj-CJ for submit@debbugs.gnu.org; Tue, 23 Feb 2021 03:00:18 -0500 Received: from mail-ot1-f42.google.com ([209.85.210.42]:36803) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEScA-0001ZQ-Oo for 46670@debbugs.gnu.org; Tue, 23 Feb 2021 03:00:15 -0500 Received: by mail-ot1-f42.google.com with SMTP id 105so8306235otd.3 for <46670@debbugs.gnu.org>; Tue, 23 Feb 2021 00:00:14 -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=IhkouAR4Tj5yq0ROW9+U7+Xth5DlFUHMuQCKRjQAx9M=; b=PAsla8/cp3hvd5zp55Z3a1bh+Pid6ol9TMNzlKyas5KC593zjcvM6aTWxspNdc5ZJo +puxxbugTL8u3PGfKL+aVks/wd6tCJScpmdH3ZfNocwXs766yFFdfQ4ifY7Fq91lRF+s 9N2Fqcv1vXyZZTCj0VHBYr13EbeL/9SeXecj1XT5dSn0+nVHDuPhzPYBqX/HMRD13yX7 S2VgTwX2hVSDR6iIbOP/vzgq1SU3CLjrAolbGzjFfPOCgDOjGjCtpKdDay86GuNlP3uh 6yO+qmDuvXCKCQ4ySrRawQD/Nhc8I2a9N9yAT/Skhcw6WMdgkGaiAriOC9nXdAMKXrSA qafg== 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=IhkouAR4Tj5yq0ROW9+U7+Xth5DlFUHMuQCKRjQAx9M=; b=IAQfVGzrJVUSpRw/adoTW1W7mS6kA0djBhFtVOynuxCHc05dOXaNvXvDxzVtanu1LX wuDV8PY+atbKWWGTQUCCWL65q/908AKnP8lF1N4FvaX24GEdXRGJvpAZ/LH0Vk4mLlvx ikGaqFMrFSDLqz+vokw2s7eiBeAHIPs2a8V2F9SsNoUU1o1muhQK+Cow46GfOv7TTdm8 flE/RH8SP0lOnjH+jm1uj9NpwX/1Fg8Ir0wuRSI3+qEw3WVmacD6OrFu9BpIrFhni8lQ u9v3fdZ8M+IqRLXM1PBLIXo8UwFhw2b7EGL2wIFCqJmCumr/6t9BYNqJtgb93BF0yoT2 cqFA== X-Gm-Message-State: AOAM5339+uJvfh9crlPFOvBmgOy5HF5UWwaJbhg6izXmcPSWrq+yYLXe UDMyJHm8oQgw+oZAs228yHx00e3k8tvhg8iLloc= X-Google-Smtp-Source: ABdhPJzybcQo+YUzZUMS9Czd3fluXlrTSF8ZXnYjjuRs2HXeC+sMz2HvMyd+Yaom6U9A4hCSfAjrydvDhbo4UJn2oew= X-Received: by 2002:a05:6830:249a:: with SMTP id u26mr14469318ots.287.1614067209137; Tue, 23 Feb 2021 00:00:09 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Tue, 23 Feb 2021 07:59:32 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: multipart/mixed; boundary="000000000000a5273005bbfc4e5e" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000a5273005bbfc4e5e Content-Type: text/plain; charset="UTF-8" On Mon, Feb 22, 2021 at 1:12 PM Andrea Corallo wrote: > Good catch thanks! :) Should be fixed by d6227f6edc. I'm also confused by the use of NEGATED in comp-emit-assume: if RHS is a constraint, it emits the complementary constraint. However, the code in comp-add-cond-cstrs uses NEGATED to express a much weaker constraint: that two mvars aren't strictly equal. If x /= y and y in SET, we can't conclude that x not in SET (unless SET is a singleton, an important special case). So it all works right now because emit-assume NEGATED=t RHS=mvar means "LHS isn't equal to RHS" but NEGATED=t RHS=cstr means "LHS can't satisfy RHS". My code changed the call to pass a constraint instead of the mvar, and then things broke :-) We should be consistent about what NEGATED means, I think. But apart from such problems, my code appears to be working. I'm attaching it for the sake of completeness, not because I expect you to read it all before it's cleaned up. --000000000000a5273005bbfc4e5e Content-Type: text/x-patch; charset="US-ASCII"; name="emacs-bug46670-001.diff" Content-Disposition: attachment; filename="emacs-bug46670-001.diff" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_klhpwpto0 ZGlmZiAtLWdpdCBhL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsIGIvbGlzcC9lbWFjcy1saXNwL2Nv bXAuZWwKaW5kZXggNjBjMDQwOTI2ZTU0Yy4uM2NiNzgxMmI1YTg3NCAxMDA2NDQKLS0tIGEvbGlz cC9lbWFjcy1saXNwL2NvbXAuZWwKKysrIGIvbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwKQEAgLTY5 MCw2ICs2OTAsMTYgQEAgY29tcC1hcmdzLWJhc2UKICAgICAgICAgICAgICA6ZG9jdW1lbnRhdGlv biAiVGhpcyBpcyBhIGNvcHkgb2YgdGhlIGZyYW1lIHdoZW4gbGVhdmluZyB0aGUgYmxvY2suCiBJ cyBpbiB1c2UgdG8gaGVscCB0aGUgU1NBIHJlbmFtZSBwYXNzLiIpKQogCisoZGVmdW4gY29tcC1i bG9jay1pbnNucy1yZXZlcnNlIChiYiAmb3B0aW9uYWwgc3RhcnQpCisgICJSZXR1cm4gdGhlIGlu c25zIGluIEJCIGluIHJldmVyc2Ugb3JkZXIsIHN0YXJ0aW5nIHdpdGggdGhlIG9uZSBiZWZvcmUK K1NUQVJULiIKKyAgKGxldCAoKGluc25zIChjb21wLWJsb2NrLWluc25zIGJiKSkKKyAgICAgICAg cmVzKQorICAgICh3aGlsZSAobm90IChlcSAoY2FyIGluc25zKSBzdGFydCkpCisgICAgICAocHVz aCAoY2FyIGluc25zKSByZXMpCisgICAgICAoc2V0cSBpbnNucyAoY2RyIGluc25zKSkpCisgICAg cmVzKSkKKwogKGNsLWRlZnN0cnVjdCAoY29tcC1ibG9jay1sYXAgKDpjb3BpZXIgbmlsKQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKDppbmNsdWRlIGNvbXAtYmxvY2spCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoOmNvbnN0cnVjdG9yIG1ha2UtLWNvbXAtYmxvY2stbGFw CkBAIC04MjYsNyArODM2LDcgQEAgY29tcC1tdmFyLXZhbHVlLXZsZC1wCiAoZGVmdW4gY29tcC1t dmFyLXZhbHVlIChtdmFyKQogICAiUmV0dXJuIHRoZSBjb25zdGFudCB2YWx1ZSBvZiBNVkFSLgog YGNvbXAtbXZhci12YWx1ZS12bGQtcCcgKm11c3QqIGJlIHNhdGlzZmllZCBiZWZvcmUgY2FsbGlu ZwotYGNvbXAtbXZhci1jb25zdCcuIgorYGNvbXAtbXZhci12YWx1ZScuIgogICAoZGVjbGFyZSAo Z3Ytc2V0dGVyCiAgICAgICAgICAgICAobGFtYmRhICh2YWwpCiAgICAgICAgICAgICAgIGAoaWYg KGludGVnZXJwICx2YWwpCkBAIC05MDMsNiArOTEzLDEwIEBAIGNvbXAtYXNzaWduLW9wLXAKICAg IkFzc2lnbm1lbnQgcHJlZGljYXRlIGZvciBPUC4iCiAgICh3aGVuIChtZW1xIG9wIGNvbXAtbGlt cGxlLWFzc2lnbm1lbnRzKSB0KSkKIAorKGRlZnVuIGNvbXAtY2xvYmJlcmluZy1hc3NpZ24tb3At cCAob3ApCisgICJUZXN0IGlmIE9QIGlzIGEgY2xvYmJlcmluZyBhc3NpZ25tZW50LiIKKyAgKGFu ZCAoY29tcC1hc3NpZ24tb3AtcCBvcCkgKG5vdCAoZXEgb3AgJ2Fzc3VtZSkpKSkKKwogKGRlZnVu IGNvbXAtY2FsbC1vcC1wIChvcCkKICAgIkNhbGwgcHJlZGljYXRlIGZvciBPUC4iCiAgICh3aGVu IChtZW1xIG9wIGNvbXAtbGltcGxlLWNhbGxzKSB0KSkKQEAgLTIyMDIsNyArMjIxNiw3IEBAIGNv bXAtbGltcGxpZnkKIAogCiAoZGVmc3Vic3QgY29tcC1tdmFyLXVzZWQtcCAobXZhcikKLSAgIk5v bi1uaWwgd2hlbiBNVkFSIGlzIHVzZWQgYXMgbGhzIGluIHRoZSBjdXJyZW50IGZ1bmNpdG9uLiIK KyAgIk5vbi1uaWwgd2hlbiBNVkFSIGlzIHVzZWQgYXMgcmhzIGluIHRoZSBjdXJyZW50IGZ1bmN0 aW9uLiIKICAgKGRlY2xhcmUgKGd2LXNldHRlciAobGFtYmRhICh2YWwpCiAJCQlgKHB1dGhhc2gg LG12YXIgLHZhbCBjb21wLXBhc3MpKSkpCiAgIChnZXRoYXNoIG12YXIgY29tcC1wYXNzKSkKQEAg LTIyMTcsNyArMjIzMSw3IEBAIGNvbXAtY29sbGVjdC1tdmFycwogICAgICAgICAgICAgICAgZG8g KHNldGYgKGNvbXAtbXZhci11c2VkLXAgeCkgdCkpKQogCiAoZGVmdW4gY29tcC1jb2xsZWN0LXJo cyAoKQotICAiQ29sbGVjdCBhbGwgbGhzIG12YXJzIGludG8gYGNvbXAtcGFzcycuIgorICAiQ29s bGVjdCBhbGwgcmhzIG12YXJzIGludG8gYGNvbXAtcGFzcycuIgogICAoY2wtbG9vcAogICAgZm9y IGIgYmVpbmcgZWFjaCBoYXNoLXZhbHVlIG9mIChjb21wLWZ1bmMtYmxvY2tzIGNvbXAtZnVuYykK ICAgIGRvIChjbC1sb29wCkBAIC0yMjQ1LDcgKzIyNTksMTQgQEAgY29tcC1yZXZlcnNlLWNtcC1m dW4KICAgICAoPD0gJz49KQogICAgICh0IGZ1bmN0aW9uKSkpCiAKLShkZWZ1biBjb21wLWVtaXQt YXNzdW1lIChraW5kIGxocyByaHMgYmIgbmVnYXRlZCkKKyhkZWZ1biBjb21wLWNzdHItc2luZ2xl dG9uLXAgKGNzdHIpCisgIChvciAoYW5kIChjb21wLWNzdHItdmFsc2V0IGNzdHIpCisgICAgICAg ICAgIChsZW5ndGg9IChjb21wLWNzdHItdmFsc2V0IGNzdHIpIDEpKQorICAgICAgKGFuZCAoY29t cC1jc3RyLXJhbmdlIGNzdHIpCisgICAgICAgICAgIChlcXVhbCAoY2FyIChjb21wLWNzdHItcmFu Z2UgY3N0cikpCisgICAgICAgICAgICAgICAgICAoY2RyIChjb21wLWNzdHItcmFuZ2UgY3N0cikp KSkpKQorCisoZGVmdW4gY29tcC1lbWl0LWFzc3VtZSAoa2luZCBsaHMgcmhzIGJiIG5lZ2F0ZWQg Jm9wdGlvbmFsIHN0cmljdGx5KQogICAiRW1pdCBhbiBhc3N1bWUgb2Yga2luZCBLSU5EIGZvciBt dmFyIExIUyBiZWluZyBSSFMuCiBXaGVuIE5FR0FURUQgaXMgbm9uLW5pbCB0aGUgYXNzdW1wdGlv biBpcyBuZWdhdGVkLgogVGhlIGFzc3VtZSBpcyBlbWl0dGVkIGF0IHRoZSBiZWdpbm5pbmcgb2Yg dGhlIGJsb2NrIEJCLiIKQEAgLTIyNTMsNiArMjI3NCw3IEBAIGNvbXAtZW1pdC1hc3N1bWUKICAg ICAoY2wtYXNzZXJ0IGxocy1zbG90KQogICAgIChwY2FzZSBraW5kCiAgICAgICAoJ2FuZAorICAg ICAgIChjb21wLWxvZyAoZm9ybWF0ICJhc3N1bWluZzQgJVMgJVMgJVMiIGxocyByaHMgbmVnYXRl ZCkpCiAgICAgICAgKGlmIChjb21wLW12YXItcCByaHMpCiAgICAgICAgICAgIChsZXQgKCh0bXAt bXZhciAoaWYgbmVnYXRlZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChtYWtlLWNv bXAtbXZhciA6c2xvdCAoY29tcC1tdmFyLXNsb3QgcmhzKSkKQEAgLTIyNjMsMjkgKzIyODUsNDcg QEAgY29tcC1lbWl0LWFzc3VtZQogICAgICAgICAgICAgIChpZiBuZWdhdGVkCiAgICAgICAgICAg ICAgICAgIChwdXNoIGAoYXNzdW1lICx0bXAtbXZhciAobm90ICxyaHMpKQogCSAgICAgICAgICAg ICAgIChjb21wLWJsb2NrLWluc25zIGJiKSkpKQotICAgICAgICAgOzsgSWYgaXMgb25seSBhIGNv bnN0cmFpbnQgd2UgY2FuIG5lZ2F0ZSBpdCBkaXJlY3RseS4KLSAgICAgICAgIChwdXNoIGAoYXNz dW1lICwobWFrZS1jb21wLW12YXIgOnNsb3QgbGhzLXNsb3QpCi0gICAgICAgICAgICAgICAgICAg ICAgICAoYW5kICxsaHMgLChpZiBuZWdhdGVkCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAoY29tcC1jc3RyLW5lZ2F0aW9uLW1ha2UgcmhzKQotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHJocykpKQotCSAgICAgICAoY29tcC1ibG9jay1pbnNucyBi YikpKSkKKyAgICAgICAgIDs7IElmIFJIUyBpcyBhIGNvbnN0cmFpbnQgd2UgY2FuIG5lZ2F0ZSBp dCBkaXJlY3RseS4KKyAgICAgICAgIChjb21wLWxvZyAoZm9ybWF0ICJhc3N1bWluZzMgJVMgJVMi IGxocyByaHMpKQorICAgICAgICAgKHdoZW4gKG9yIHN0cmljdGx5IChub3QgbmVnYXRlZCkpCisg ICAgICAgICAgIChwdXNoIGAoYXNzdW1lICwobWFrZS1jb21wLW12YXIgOnNsb3QgbGhzLXNsb3Qp CisgICAgICAgICAgICAgICAgICAgICAgICAgIChhbmQgLGxocyAsKGlmIG5lZ2F0ZWQKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNvbXAtY3N0ci1uZWdhdGlvbi1t YWtlIHJocykKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJocykpKQor CSAgICAgICAgIChjb21wLWJsb2NrLWluc25zIGJiKSkpKSkKICAgICAgICgocHJlZCBjb21wLXJh bmdlLWNtcC1mdW4tcCkKLSAgICAgICAobGV0ICgoa2luZCAoaWYgbmVnYXRlZAotICAgICAgICAg ICAgICAgICAgICAgICAoY29tcC1uZWdhdGUtcmFuZ2UtY21wLWZ1biBraW5kKQotICAgICAgICAg ICAgICAgICAgICAga2luZCkpKQotICAgICAgICAgKHB1c2ggYChhc3N1bWUgLChtYWtlLWNvbXAt bXZhciA6c2xvdCBsaHMtc2xvdCkKLSAgICAgICAgICAgICAgICAgICAgICAgICgsa2luZCAsbGhz Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLChpZi1sZXQqICgodmxkIChjb21wLW12 YXItdmFsdWUtdmxkLXAgcmhzKSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICh2YWwgKGNvbXAtbXZhci12YWx1ZSByaHMpKQotICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKG9rIChpbnRlZ2VycCB2YWwpKSkKLSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHZhbAotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIChtYWtlLWNvbXAtbXZhciA6c2xvdCAoY29tcC1tdmFyLXNsb3QgcmhzKSkpKSkKLQkgICAg ICAgKGNvbXAtYmxvY2staW5zbnMgYmIpKSkpCisgICAgICAgKHdoZW4gKG9yIHN0cmljdGx5IChu b3QgbmVnYXRlZCkgKGNvbXAtbXZhci1wIHJocykKKyAgICAgICAgICAgICAgICAgICAoY29tcC1j c3RyLXNpbmdsZXRvbi1wIHJocykpCisgICAgICAgICAobGV0ICgoa2luZCAoaWYgbmVnYXRlZAor ICAgICAgICAgICAgICAgICAgICAgICAgIChjb21wLW5lZ2F0ZS1yYW5nZS1jbXAtZnVuIGtpbmQp CisgICAgICAgICAgICAgICAgICAgICAgIGtpbmQpKSkKKyAgICAgICAgICAgKGNvbXAtbG9nIChm b3JtYXQgImFzc3VtaW5nMiAlUyAlUyIgbGhzIHJocykpCisgICAgICAgICAgIChwdXNoIGAoYXNz dW1lICwobWFrZS1jb21wLW12YXIgOnNsb3QgbGhzLXNsb3QpCisgICAgICAgICAgICAgICAgICAg ICAgICAgICgsa2luZCAsbGhzCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAsKGlm IChjb21wLW12YXItcCByaHMpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IChpZi1sZXQqICgodmxkIChjb21wLW12YXItdmFsdWUtdmxkLXAgcmhzKSkKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICh2YWwgKGNvbXAtbXZhci12YWx1 ZSByaHMpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KG9rIChpbnRlZ2VycCB2YWwpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHZhbAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChtYWtl LWNvbXAtbXZhciA6c2xvdCAoY29tcC1tdmFyLXNsb3QgcmhzKSkpCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAoY29tcC1jc3RyLWNvcHkgcmhzKSkpKQorCSAgICAgICAgIChj b21wLWJsb2NrLWluc25zIGJiKSkpKSkKICAgICAgIChfIChjbC1hc3NlcnQgbmlsKSkpCiAgICAg KHNldGYgKGNvbXAtZnVuYy1zc2Etc3RhdHVzIGNvbXAtZnVuYykgJ2RpcnR5KSkpCiAKKyhkZWZ1 biBjb21wLWVtaXQtYXNzdW1lcyAoa2luZCBsaHNsIHJoc2wgYmFzaWMtYmxvY2sgbmVnYXRlZCAm b3B0aW9uYWwgc3RyaWN0bHkpCisgICJFbWl0IGFzc3VtZSBpbnNucyBzdGF0aW5nIHRoYXQgYWxs IGVsZW1lbnRzIG9mIExIU0wgcmVsYXRlIHRvCithbGwgZWxlbWVudHMgb2YgUkhTTCBhcyBLSU5E LCB3aGljaCBtYXkgYmUgTkVHQVRFRC4gIFRoZSBpbnNucworYXJhIGFkZGVkIHRvIEJBU0lDLUJM T0NLLiIKKyAgKGNvbXAtbG9nIChmb3JtYXQgImFzc3VtZXMgJVMgJVMiIGxoc2wgcmhzbCkpCisg IChkb2xpc3QgKGxocyBsaHNsKQorICAgIChhbmQgKGNvbXAtbXZhci1wIGxocykKKyAgICAgICAg IChjb21wLW12YXItc2xvdCBsaHMpCisgICAgICAgICAoZG9saXN0IChyaHMgcmhzbCkKKyAgICAg ICAgICAgKGNvbXAtZW1pdC1hc3N1bWUga2luZCBsaHMgcmhzIGJhc2ljLWJsb2NrIG5lZ2F0ZWQg c3RyaWN0bHkpKSkpKQorCiAoZGVmdW4gY29tcC1hZGQtbmV3LWJsb2NrLWJldHdlZW4gKGJiLXN5 bWJvbCBiYi1hIGJiLWIpCi0gICJDcmVhdGUgYSBuZXcgYmFzaWMtYmxvY2sgbmFtZWQgQkItU1lN Qk9MIGFuZCBhZGQgaXQgYmV0d2VlbiBCQi1BIGFuZCBCQi1CLiIKKyAgIkNyZWF0ZSBhIG5ldyBi YXNpYyBibG9jayBuYW1lZCBCQi1TWU1CT0wgYW5kIGFkZCBpdCBiZXR3ZWVuIEJCLUEgYW5kIEJC LUIuIgogICAoY2wtbG9vcAogICAgd2l0aCBuZXctYmIgPSAobWFrZS1jb21wLWJsb2NrLWNzdHIg Om5hbWUgYmItc3ltYm9sCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6 aW5zbnMgYCgoanVtcCAsKGNvbXAtYmxvY2stbmFtZSBiYi1iKSkpKQpAQCAtMjMwNSwyNCArMjM0 NSw4NCBAQCBjb21wLWFkZC1uZXctYmxvY2stYmV0d2VlbgogICAgOzsgQWRkIGBuZXctZWRnZScg dG8gdGhlIGN1cnJlbnQgZnVuY3Rpb24gYW5kIHJldHVybiBpdC4KICAgIChjbC1yZXR1cm4gKHB1 dGhhc2ggYmItc3ltYm9sIG5ldy1iYiAoY29tcC1mdW5jLWJsb2NrcyBjb21wLWZ1bmMpKSkKICAg IGZpbmFsbHkgKGNsLWFzc2VydCBuaWwpKSkKLQotOzsgQ2hlYXAgc3Vic3RpdHV0ZSB0byBhIGNv cHkgcHJvcGFnYXRpb24gcGFzcy4uLgotKGRlZnVuIGNvbXAtY29uZC1jc3Rycy10YXJnZXQtbXZh ciAobXZhciBleGl0LWluc24gYmIpCi0gICJHaXZlbiBNVkFSIHNlYXJjaCBpbiBCQiB0aGUgb3Jp Z2luYWwgbXZhciBNVkFSIGdvdCBhc3NpZ25lZCBmcm9tLgotS2VlcCBvbiBzZWFyY2hpbmcgdGls bCBFWElULUlOU04gaXMgZW5jb3VudGVyZWQuIgotICAoY2wtZmxldCAoKHRhcmdldHAgKHgpCi0g ICAgICAgICAgICAgIDs7IFJldCB0IGlmIHggaXMgYW4gbXZhciBhbmQgdGFyZ2V0IHRoZSBjb3Jy ZWN0IHNsb3QgbnVtYmVyLgotICAgICAgICAgICAgICAoYW5kIChjb21wLW12YXItcCB4KQotICAg ICAgICAgICAgICAgICAgIChlcWwgKGNvbXAtbXZhci1zbG90IG12YXIpIChjb21wLW12YXItc2xv dCB4KSkpKSkKLSAgICAoY2wtbG9vcAotICAgICB3aXRoIHJlcyA9IG5pbAotICAgICBmb3IgaW5z biBpbiAoY29tcC1ibG9jay1pbnNucyBiYikKLSAgICAgd2hlbiAoZXEgaW5zbiBleGl0LWluc24p Ci0gICAgIGRvIChjbC1yZXR1cm4gKGFuZCAoY29tcC1tdmFyLXAgcmVzKSByZXMpKQotICAgICBk byAocGNhc2UgaW5zbgotICAgICAgICAgIChgKCwocHJlZCBjb21wLWFzc2lnbi1vcC1wKSAsKHBy ZWQgdGFyZ2V0cCkgLHJocykKLSAgICAgICAgICAgKHNldGYgcmVzIHJocykpKQotICAgICBmaW5h bGx5IChjbC1hc3NlcnQgbmlsKSkpKQorOzsgIkNoZWFwIiBzdWJzdGl0dXRlIGZvciBhIGNvcHkg cHJvcGFnYXRpb24gcGFzcy4uLgorKGRlZnVuIGNvbXAtY29uZC1jc3Rycy1pZGVudGljYWwtdmFy cyAobXZhcnMgYmIgaW5zbikKKyAgIlNlYXJjaCBCQiBmb3IgbXZhcnMga25vd24gdG8gYmUgYGVx JyB0byBhbGwgb2YgdGhlIE1WQVJTIGF0IHRoZSB0aW1lIElOU04KK2lzIGV4ZWN1dGVkLiIKKyAg KGNsLWFzc2VydCAoY2wtZXZlcnkgIydjb21wLW12YXItcCBtdmFycykpCisgIChjbC1sb29wCisg ICB3aXRoIHNsb3RzID0gKGRlbHEgbmlsIChtYXBjYXIgIydjb21wLW12YXItc2xvdCBtdmFycykp CisgICB3aXRoIHJlcyA9IChjb3B5LXNlcXVlbmNlIG12YXJzKQorICAgd2l0aCBjbG9iYmVyZWQg PSBuaWwKKyAgIGZvciBpbnNuIGluIChjb21wLWJsb2NrLWluc25zLXJldmVyc2UgYmIgaW5zbikK KyAgIGRvIChwcm9nbgorICAgICAgICAoY29tcC1sb2cgKGZvcm1hdCAiaW5zbiAlUyBzbG90cyAl UyByZXMgJVMgY2xvYmJlcmVkICVTIgorICAgICAgICAgICAgICAgICAgICAgICAgICBpbnNuIHNs b3RzIHJlcyBjbG9iYmVyZWQpKQorICAgICAgICAocGNhc2UgaW5zbgorICAgICAgICAoYCgsKGFu ZCBvcCAocHJlZCBjb21wLWFzc2lnbi1vcC1wKSkKKyAgICAgICAgICAgLChhbmQgKHByZWQgY29t cC1tdmFyLXApIChwcmVkIGNvbXAtbXZhci1zbG90KSBsaHMpCisgICAgICAgICAgICwoYW5kIChw cmVkIGNvbXAtbXZhci1wKSAocHJlZCBjb21wLW12YXItc2xvdCkgcmhzKSkKKyAgICAgICAgIChs ZXQgKChsaHMtcCAobWVtYmVyIChjb21wLW12YXItc2xvdCBsaHMpIHNsb3RzKSkKKyAgICAgICAg ICAgICAgIChyaHMtcCAobWVtYmVyIChjb21wLW12YXItc2xvdCByaHMpIHNsb3RzKSkpCisgICAg ICAgICAgIChhbmQgbGhzLXAgKG5vdCByaHMtcCkKKyAgICAgICAgICAgICAgICAocHVzaCAoY29t cC1tdmFyLXNsb3QgcmhzKSBzbG90cykKKyAgICAgICAgICAgICAgICAodW5sZXNzIChvciAobWVt YmVyIChjb21wLW12YXItc2xvdCBsaHMpIGNsb2JiZXJlZCkKKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAobWVtcSByaHMgcmVzKSkKKyAgICAgICAgICAgICAgICAgIChwdXNoIHJocyByZXMp KSkKKyAgICAgICAgICAgKGFuZCByaHMtcCAobm90IGxocy1wKQorICAgICAgICAgICAgICAgIChw dXNoIChjb21wLW12YXItc2xvdCBsaHMpIHNsb3RzKQorICAgICAgICAgICAgICAgICh1bmxlc3Mg KG9yIChtZW1iZXIgKGNvbXAtbXZhci1zbG90IHJocykgY2xvYmJlcmVkKQorICAgICAgICAgICAg ICAgICAgICAgICAgICAgIChtZW1xIGxocyByZXMpKQorICAgICAgICAgICAgICAgICAgKHB1c2gg bGhzIHJlcykpKQorICAgICAgICAgICAoYW5kIChjb21wLWNsb2JiZXJpbmctYXNzaWduLW9wLXAg b3ApCisgICAgICAgICAgICAgICAgKG5vdCBsaHMtcCkKKyAgICAgICAgICAgICAgICAobm90IHJo cy1wKQorICAgICAgICAgICAgICAgIChzZXRxIHNsb3RzIChkZWxldGUgKGNvbXAtbXZhci1zbG90 IGxocykgc2xvdHMpKQorICAgICAgICAgICAgICAgICh1bmxlc3MgKG1lbWJlciAoY29tcC1tdmFy LXNsb3QgbGhzKSBjbG9iYmVyZWQpCisgICAgICAgICAgICAgICAgICAocHVzaCAoY29tcC1tdmFy LXNsb3QgbGhzKSBjbG9iYmVyZWQpKSkpCisgICAgICAgICAoY29tcC1sb2cgKGZvcm1hdCAicG9z dCBpbnNuICVTIHNsb3RzICVTIHJlcyAlUyBjbG9iYmVyZWQgJVMiCisgICAgICAgICAgICAgICAg ICAgICAgICAgICBpbnNuIHNsb3RzIHJlcyBjbG9iYmVyZWQpKSkKKyAgICAgICAgKGAoLChwcmVk IGNvbXAtY2xvYmJlcmluZy1hc3NpZ24tb3AtcCkKKyAgICAgICAgICAgLChhbmQgKHByZWQgY29t cC1tdmFyLXNsb3QpIGxocykKKyAgICAgICAgICAgXykKKyAgICAgICAgICh1bmxlc3MgKG1lbWJl ciAoY29tcC1tdmFyLXNsb3QgbGhzKSBjbG9iYmVyZWQpCisgICAgICAgICAgIChwdXNoIChjb21w LW12YXItc2xvdCBsaHMpIGNsb2JiZXJlZCkpCisgICAgICAgICAoc2V0cSBzbG90cyAoZGVsZXRl IChjb21wLW12YXItc2xvdCBsaHMpIHNsb3RzKSkpKSkKKyAgIGZpbmFsbHkgKHByb2duCisgICAg ICAgICAgICAgKGNsLXJldHVybiByZXMpKSkpCisKKzs7ICJDaGVhcCIgc3Vic3RpdHV0ZSBmb3Ig YSBjb3B5IHByb3BhZ2F0aW9uIHBhc3MuLi4KKyhkZWZ1biBjb21wLWNvbmQtY3N0cnMtaWRlbnRp Y2FsLXZhcnMtYnl2YXIgKG12YXJzIGJiIGluc24pCisgICJTZWFyY2ggQkIgZm9yIG12YXJzIGtu b3duIHRvIGJlIGBlcScgdG8gYWxsIG9mIHRoZSBNVkFSUyBhdCB0aGUgdGltZSBJTlNOCitpcyBl eGVjdXRlZC4gRXhjbHVkZSB0aGUgTVZBUlMgdGhlbXNlbHZlcyBmcm9tIHRoZSByZXN1bHQuIgor ICAoY2wtYXNzZXJ0IChjbC1ldmVyeSAjJ2NvbXAtbXZhci1wIG12YXJzKSkKKyAgKGNsLWxvb3AK KyAgIHdpdGggdmFycyA9IChjb3B5LXNlcXVlbmNlIG12YXJzKQorICAgd2l0aCByZXMgPSBuaWwK KyAgIHdpdGggY2xvYmJlcmVkID0gbmlsCisgICBmb3IgaW5zbiBpbiAoY29tcC1ibG9jay1pbnNu cy1yZXZlcnNlIGJiIGluc24pCisgICBkbyAocGNhc2UgaW5zbgorICAgICAgICAoYCgsKGFuZCBv cCAocHJlZCBjb21wLWFzc2lnbi1vcC1wKSkKKyAgICAgICAgICAgLGxocworICAgICAgICAgICAs KGFuZCAocHJlZCBjb21wLW12YXItcCkgcmhzKSkKKyAgICAgICAgIChsZXQgKChsaHMtcCAobWVt cSBsaHMgdmFycykpCisgICAgICAgICAgICAgICAocmhzLXAgKG1lbXEgcmhzIHZhcnMpKSkKKyAg ICAgICAgICAgKGNvbmQKKyAgICAgICAgICAgICgoYW5kIChub3QgbGhzLXApIHJocy1wKQorICAg ICAgICAgICAgIChwdXNoIGxocyB2YXJzKQorICAgICAgICAgICAgICh1bmxlc3MgKG9yIChtZW1x IGxocyBjbG9iYmVyZWQpCisgICAgICAgICAgICAgICAgICAgICAgICAgKG1lbXEgbGhzIHJlcykp CisgICAgICAgICAgICAgICAocHVzaCBsaHMgcmVzKSkpCisgICAgICAgICAgICAoKG9yIHJocy1w IChub3QgKGNvbXAtY2xvYmJlcmluZy1hc3NpZ24tb3AtcCBvcCkpKSkKKyAgICAgICAgICAgICgo c2V0cSB2YXJzIChkZWxxIGxocyB2YXJzKSkKKyAgICAgICAgICAgICAodW5sZXNzIChtZW1xIGxo cyBjbG9iYmVyZWQpIChwdXNoIGxocyBjbG9iYmVyZWQpKSkpKSkKKyAgICAgICAgKGAoLChwcmVk IGNvbXAtY2xvYmJlcmluZy1hc3NpZ24tb3AtcCkgLGxocyBfKQorICAgICAgICAgKHVubGVzcyAo bWVtcSBsaHMgY2xvYmJlcmVkKSAocHVzaCBsaHMgY2xvYmJlcmVkKSkKKyAgICAgICAgIChzZXRx IHZhcnMgKGRlbHEgbGhzIHZhcnMpKSkpCisgICBmaW5hbGx5IChwcm9nbgorICAgICAgICAgICAg IChjb21wLWxvZyAoZm9ybWF0ICJtdmFycyAlUyByZXMgJVMiCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbXZhcnMgcmVzKSkKKyAgICAgICAgICAgICAoY2wtcmV0dXJuIHJlcykpKSkK IAogKGRlZnVuIGNvbXAtYWRkLWNvbmQtY3N0cnMtdGFyZ2V0LWJsb2NrIChjdXJyLWJiIHRhcmdl dC1iYi1zeW0pCiAgICJSZXR1cm4gdGhlIGFwcHJvcHJpYXRlIGJhc2ljIGJsb2NrIHRvIGFkZCBj b25zdHJhaW50IGFzc3VtcHRpb25zIGludG8uCkBAIC0yNDAxLDIzICsyNTAxLDQ0IEBAIGNvbXAt YWRkLWNvbmQtY3N0cnMKIAkgOzsgKGNvbW1lbnQgLF9jb21tZW50LXN0cikKIAkgKGNvbmQtanVt cCAsY21wLXJlcyAsKHByZWQgY29tcC1tdmFyLXApIC4gLGJsb2NrcykpCiAgICAgICAgKGNsLWxv b3AKLSAgICAgICAgd2l0aCB0YXJnZXQtbXZhcjEgPSAoY29tcC1jb25kLWNzdHJzLXRhcmdldC1t dmFyIG9wMSAoY2FyIGluc25zLXNlcSkgYikKLSAgICAgICAgd2l0aCB0YXJnZXQtbXZhcjIgPSAo Y29tcC1jb25kLWNzdHJzLXRhcmdldC1tdmFyIG9wMiAoY2FyIGluc25zLXNlcSkgYikKKyAgICAg ICAgd2l0aCB0YXJnZXQtbXZhcnMxID0gKGNvbXAtY29uZC1jc3Rycy1pZGVudGljYWwtdmFycwor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChsaXN0IG9wMSkgYiAoY2FyIGluc25zLXNl cSkpCisgICAgICAgIHdpdGggdGFyZ2V0LW12YXJzMiA9IChjb21wLWNvbmQtY3N0cnMtaWRlbnRp Y2FsLXZhcnMKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobGlzdCBvcDIpIGIgKGNh ciBpbnNucy1zZXEpKQogICAgICAgICB3aXRoIGVxdWFsaXR5ID0gKGNvbXAtZXF1YWxpdHktZnVu LXAgZnVuKQogICAgICAgICBmb3IgYnJhbmNoLXRhcmdldC1jZWxsIG9uIGJsb2NrcwogICAgICAg ICBmb3IgYnJhbmNoLXRhcmdldCA9IChjYXIgYnJhbmNoLXRhcmdldC1jZWxsKQogICAgICAgICBm b3IgbmVnYXRlZCBpbiAnKHQgbmlsKQogICAgICAgICBmb3Iga2luZCA9IChpZiBlcXVhbGl0eSAn YW5kIGZ1bikKLSAgICAgICAgd2hlbiAob3IgKGNvbXAtbXZhci11c2VkLXAgdGFyZ2V0LW12YXIx KQotICAgICAgICAgICAgICAgICAoY29tcC1tdmFyLXVzZWQtcCB0YXJnZXQtbXZhcjIpKQogICAg ICAgICBkbworICAgICAgICAoY29tcC1sb2cgKGZvcm1hdCAidGFyZ2V0IG12YXJzICVTICVTIgor ICAgICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQtbXZhcnMxIHRhcmdldC1tdmFyczIpKQor ICAgICAgICAoc2V0cSB0YXJnZXQtbXZhcnMxCisgICAgICAgICAgICAgIChtYXBjYXIKKyAgICAg ICAgICAgICAgIChsYW1iZGEgKG12YXIpCisgICAgICAgICAgICAgICAgIChpZiAoYW5kCisgICAg ICAgICAgICAgICAgICAgICAgKGNvbXAtbXZhci1wIG12YXIpCisgICAgICAgICAgICAgICAgICAg ICAgKGVxdWFsIChjb21wLW12YXItc2xvdCBtdmFyKQorICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAoY29tcC1tdmFyLXNsb3QgY21wLXJlcykpKQorICAgICAgICAgICAgICAgICAgICAgKGNv bXAtY3N0ci1jb3B5IG12YXIpCisgICAgICAgICAgICAgICAgICAgbXZhcikpCisgICAgICAgICAg ICAgICB0YXJnZXQtbXZhcnMxKSkKKyAgICAgICAgKHNldHEgdGFyZ2V0LW12YXJzMgorICAgICAg ICAgICAgICAobWFwY2FyCisgICAgICAgICAgICAgICAobGFtYmRhIChtdmFyKQorICAgICAgICAg ICAgICAgICAoaWYgKGFuZAorICAgICAgICAgICAgICAgICAgICAgIChjb21wLW12YXItcCBtdmFy KQorICAgICAgICAgICAgICAgICAgICAgIChlcXVhbCAoY29tcC1tdmFyLXNsb3QgbXZhcikKKyAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNvbXAtbXZhci1zbG90IGNtcC1yZXMpKSkKKyAg ICAgICAgICAgICAgICAgICAgIChjb21wLWNzdHItY29weSBtdmFyKQorICAgICAgICAgICAgICAg ICAgIG12YXIpKQorICAgICAgICAgICAgICAgdGFyZ2V0LW12YXJzMikpCiAgICAgICAgIChsZXQg KChibG9jay10YXJnZXQgKGNvbXAtYWRkLWNvbmQtY3N0cnMtdGFyZ2V0LWJsb2NrIGIgYnJhbmNo LXRhcmdldCkpKQogICAgICAgICAgIChzZXRmIChjYXIgYnJhbmNoLXRhcmdldC1jZWxsKSAoY29t cC1ibG9jay1uYW1lIGJsb2NrLXRhcmdldCkpCi0gICAgICAgICAgKHdoZW4gKGNvbXAtbXZhci11 c2VkLXAgdGFyZ2V0LW12YXIxKQotICAgICAgICAgICAgKGNvbXAtZW1pdC1hc3N1bWUga2luZCB0 YXJnZXQtbXZhcjEgb3AyIGJsb2NrLXRhcmdldCBuZWdhdGVkKSkKLSAgICAgICAgICAod2hlbiAo Y29tcC1tdmFyLXVzZWQtcCB0YXJnZXQtbXZhcjIpCi0gICAgICAgICAgICAoY29tcC1lbWl0LWFz c3VtZSAoY29tcC1yZXZlcnNlLWNtcC1mdW4ga2luZCkKLSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRhcmdldC1tdmFyMiBvcDEgYmxvY2stdGFyZ2V0IG5lZ2F0ZWQpKSkKKyAgICAgICAg ICAoY29tcC1lbWl0LWFzc3VtZXMga2luZAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 YXJnZXQtbXZhcnMxIHRhcmdldC1tdmFyczIgYmxvY2stdGFyZ2V0IG5lZ2F0ZWQpCisgICAgICAg ICAgKGNvbXAtZW1pdC1hc3N1bWVzIChjb21wLXJldmVyc2UtY21wLWZ1biBraW5kKQorICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB0YXJnZXQtbXZhcnMyIHRhcmdldC1tdmFyczEgYmxvY2st dGFyZ2V0IG5lZ2F0ZWQpKQogICAgICAgICBmaW5hbGx5IChjbC1yZXR1cm4tZnJvbSBpbi10aGUt YmFzaWMtYmxvY2spKSkKICAgICAgIChgKChzZXQgLChhbmQgKHByZWQgY29tcC1tdmFyLXApIGNt cC1yZXMpCiAgICAgICAgICAgICAgICgsKHByZWQgY29tcC1jYWxsLW9wLXApCkBAIC0yNDI2LDE2 ICsyNTQ3LDI2IEBAIGNvbXAtYWRkLWNvbmQtY3N0cnMKIAkgOzsgKGNvbW1lbnQgLF9jb21tZW50 LXN0cikKIAkgKGNvbmQtanVtcCAsY21wLXJlcyAsKHByZWQgY29tcC1tdmFyLXApIC4gLGJsb2Nr cykpCiAgICAgICAgKGNsLWxvb3AKLSAgICAgICAgd2l0aCB0YXJnZXQtbXZhciA9IChjb21wLWNv bmQtY3N0cnMtdGFyZ2V0LW12YXIgb3AgKGNhciBpbnNucy1zZXEpIGIpCisgICAgICAgIHdpdGgg dGFyZ2V0LW12YXJzID0gKGNvbXAtY29uZC1jc3Rycy1pZGVudGljYWwtdmFycworICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAobGlzdCBvcCkgYiAoY2FyIGluc25zLXNlcSkpCiAgICAgICAg IHdpdGggY3N0ciA9IChjb21wLXByZWQtdG8tY3N0ciBmdW4pCiAgICAgICAgIGZvciBicmFuY2gt dGFyZ2V0LWNlbGwgb24gYmxvY2tzCiAgICAgICAgIGZvciBicmFuY2gtdGFyZ2V0ID0gKGNhciBi cmFuY2gtdGFyZ2V0LWNlbGwpCiAgICAgICAgIGZvciBuZWdhdGVkIGluICcodCBuaWwpCi0gICAg ICAgIHdoZW4gKGNvbXAtbXZhci11c2VkLXAgdGFyZ2V0LW12YXIpCisgICAgICAgIHdoZW4gdGFy Z2V0LW12YXJzCiAgICAgICAgIGRvCisgICAgICAgIChzZXRxIHRhcmdldC1tdmFycworICAgICAg ICAgICAgICAobWFwY2FyIChsYW1iZGEgKG12YXIpCisgICAgICAgICAgICAgICAgICAgICAgICAo aWYgKGFuZAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY29tcC1tdmFyLXAgbXZhcikK KyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGVxdWFsIChjb21wLW12YXItc2xvdCBtdmFy KQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGNvbXAtbXZhci1zbG90IGNt cC1yZXMpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY29tcC1jc3RyLWNvcHkgbXZh cikKKyAgICAgICAgICAgICAgICAgICAgICAgICAgbXZhcikpCisgICAgICAgICAgICAgICAgICAg ICAgdGFyZ2V0LW12YXJzKSkKICAgICAgICAgKGxldCAoKGJsb2NrLXRhcmdldCAoY29tcC1hZGQt Y29uZC1jc3Rycy10YXJnZXQtYmxvY2sgYiBicmFuY2gtdGFyZ2V0KSkpCiAgICAgICAgICAgKHNl dGYgKGNhciBicmFuY2gtdGFyZ2V0LWNlbGwpIChjb21wLWJsb2NrLW5hbWUgYmxvY2stdGFyZ2V0 KSkKLSAgICAgICAgICAoY29tcC1lbWl0LWFzc3VtZSAnYW5kIHRhcmdldC1tdmFyIGNzdHIgYmxv Y2stdGFyZ2V0IG5lZ2F0ZWQpKQorICAgICAgICAgIChjb21wLWVtaXQtYXNzdW1lcyAnYW5kIHRh cmdldC1tdmFycyAobGlzdCBjc3RyKSBibG9jay10YXJnZXQgbmVnYXRlZCB0KSkKICAgICAgICAg ZmluYWxseSAoY2wtcmV0dXJuLWZyb20gaW4tdGhlLWJhc2ljLWJsb2NrKSkpCiAgICAgICA7OyBN YXRjaCBwcmVkaWNhdGUgb24gdGhlIG5lZ2F0ZWQgYnJhbmNoICh1bmxlc3MpLgogICAgICAgKGAo KHNldCAsKGFuZCAocHJlZCBjb21wLW12YXItcCkgY21wLXJlcykKQEAgLTI0NDUsMTYgKzI1NzYs MjcgQEAgY29tcC1hZGQtY29uZC1jc3RycwogICAgICAgICAgKHNldCAsbmVnLWNtcC1yZXMgKGNh bGwgZXEgLGNtcC1yZXMgLChwcmVkIGNvbXAtY3N0ci1udWxsLXApKSkKIAkgKGNvbmQtanVtcCAs bmVnLWNtcC1yZXMgLChwcmVkIGNvbXAtbXZhci1wKSAuICxibG9ja3MpKQogICAgICAgIChjbC1s b29wCi0gICAgICAgIHdpdGggdGFyZ2V0LW12YXIgPSAoY29tcC1jb25kLWNzdHJzLXRhcmdldC1t dmFyIG9wIChjYXIgaW5zbnMtc2VxKSBiKQorICAgICAgICB3aXRoIHRhcmdldC1tdmFycyA9IChj b21wLWNvbmQtY3N0cnMtaWRlbnRpY2FsLXZhcnMKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKGxpc3Qgb3ApIGIgKGNhciBpbnNucy1zZXEpKQogICAgICAgICB3aXRoIGNzdHIgPSAoY29t cC1wcmVkLXRvLWNzdHIgZnVuKQogICAgICAgICBmb3IgYnJhbmNoLXRhcmdldC1jZWxsIG9uIGJs b2NrcwogICAgICAgICBmb3IgYnJhbmNoLXRhcmdldCA9IChjYXIgYnJhbmNoLXRhcmdldC1jZWxs KQogICAgICAgICBmb3IgbmVnYXRlZCBpbiAnKG5pbCB0KQotICAgICAgICB3aGVuIChjb21wLW12 YXItdXNlZC1wIHRhcmdldC1tdmFyKQorICAgICAgICB3aGVuIHRhcmdldC1tdmFycwogICAgICAg ICBkbworICAgICAgICAoc2V0cSB0YXJnZXQtbXZhcnMKKyAgICAgICAgICAgICAgKG1hcGNhcgor ICAgICAgICAgICAgICAgKGxhbWJkYSAobXZhcikKKyAgICAgICAgICAgICAgICAgKGlmIChhbmQK KyAgICAgICAgICAgICAgICAgICAgICAoY29tcC1tdmFyLXAgbXZhcikKKyAgICAgICAgICAgICAg ICAgICAgICAoZXF1YWwgKGNvbXAtbXZhci1zbG90IG12YXIpCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIChjb21wLW12YXItc2xvdCBjbXAtcmVzKSkpCisgICAgICAgICAgICAgICAgICAg ICAoY29tcC1jc3RyLWNvcHkgbXZhcikKKyAgICAgICAgICAgICAgICAgICBtdmFyKSkKKyAgICAg ICAgICAgICAgIHRhcmdldC1tdmFycykpCiAgICAgICAgIChsZXQgKChibG9jay10YXJnZXQgKGNv bXAtYWRkLWNvbmQtY3N0cnMtdGFyZ2V0LWJsb2NrIGIgYnJhbmNoLXRhcmdldCkpKQogICAgICAg ICAgIChzZXRmIChjYXIgYnJhbmNoLXRhcmdldC1jZWxsKSAoY29tcC1ibG9jay1uYW1lIGJsb2Nr LXRhcmdldCkpCi0gICAgICAgICAgKGNvbXAtZW1pdC1hc3N1bWUgJ2FuZCB0YXJnZXQtbXZhciBj c3RyIGJsb2NrLXRhcmdldCBuZWdhdGVkKSkKKyAgICAgICAgICAoY29tcC1lbWl0LWFzc3VtZXMg J2FuZCB0YXJnZXQtbXZhcnMgKGxpc3QgY3N0cikgYmxvY2stdGFyZ2V0IG5lZ2F0ZWQgdCkpCiAg ICAgICAgIGZpbmFsbHkgKGNsLXJldHVybi1mcm9tIGluLXRoZS1iYXNpYy1ibG9jaykpKSkpKSkK IAogKGRlZnN1YnN0IGNvbXAtaW5zZXJ0LWluc24gKGluc24gaW5zbi1jZWxsKQpAQCAtMjQ2NSwx MyArMjYwNywxNCBAQCBjb21wLWluc2VydC1pbnNuCiAgICAgICAgICAgKGNkciBuZXctY2VsbCkg bmV4dC1jZWxsCiAgICAgICAgICAgKGNvbXAtZnVuYy1zc2Etc3RhdHVzIGNvbXAtZnVuYykgJ2Rp cnR5KSkpCiAKLShkZWZ1biBjb21wLWVtaXQtY2FsbC1jc3RyIChtdmFyIGNhbGwtY2VsbCBjc3Ry KQorKGRlZnVuIGNvbXAtZW1pdC1jYWxsLWNzdHJzIChtdmFycyBjYWxsLWNlbGwgY3N0cikKICAg IkVtaXQgYSBjb25zdHJhaW50IENTVFIgZm9yIE1WQVIgYWZ0ZXIgQ0FMTC1DRUxMLiIKLSAgKGxl dCogKChuZXctbXZhciAobWFrZS1jb21wLW12YXIgOnNsb3QgKGNvbXAtbXZhci1zbG90IG12YXIp KSkKLSAgICAgICAgIDs7IEhhdmUgbmV3LW12YXIgYXMgTEhTICphbmQqIFJIUyB0byBlbnN1cmUg bW9ub3RvbmljaXR5IGFuZAotICAgICAgICAgOzsgZndwcm9wIGNvbnZlcmdlbmNlISEKLSAgICAg ICAgIChpbnNuIGAoYXNzdW1lICxuZXctbXZhciAoYW5kICxuZXctbXZhciAsbXZhciAsY3N0cikp KSkKLSAgICAoY29tcC1pbnNlcnQtaW5zbiBpbnNuIGNhbGwtY2VsbCkpKQorICAoZG9saXN0ICht dmFyIChjbC1yZW1vdmUtaWYtbm90ICMnY29tcC1tdmFyLXAgbXZhcnMpKQorICAgIChsZXQqICgo bmV3LW12YXIgKG1ha2UtY29tcC1tdmFyIDpzbG90IChjb21wLW12YXItc2xvdCBtdmFyKSkpCisg ICAgICAgICAgIDs7IEhhdmUgbmV3LW12YXIgYXMgTEhTICphbmQqIFJIUyB0byBlbnN1cmUgbW9u b3RvbmljaXR5IGFuZAorICAgICAgICAgICA7OyBmd3Byb3AgY29udmVyZ2VuY2UhIQorICAgICAg ICAgICAoaW5zbiBgKGFzc3VtZSAsbmV3LW12YXIgKGFuZCAsbmV3LW12YXIgLG12YXIgLGNzdHIp KSkpCisgICAgICAoY29tcC1pbnNlcnQtaW5zbiBpbnNuIGNhbGwtY2VsbCkpKSkKIAogKGRlZnVu IGNvbXAtbGFtYmRhLWxpc3QtZ2VuIChsYW1iZGEtbGlzdCkKICAgIlJldHVybiBhIGdlbmVyYXRv ciB0byBpdGVyYXRlIG92ZXIgTEFNQkRBLUxJU1QuIgpAQCAtMjUwOCwxOCArMjY1MSwyNCBAQCBj b21wLWFkZC1jYWxsLWNzdHIKICAgICAgICAgICB3aXRoIGdlbiA9IChjb21wLWxhbWJkYS1saXN0 LWdlbiAoY29tcC1jc3RyLWYtYXJncyBjc3RyLWYpKQogICAgICAgICAgIGZvciBhcmcgaW4gYXJn cwogICAgICAgICAgIGZvciBjc3RyID0gKGZ1bmNhbGwgZ2VuKQotICAgICAgICAgIGZvciB0YXJn ZXQgPSAoY29tcC1jb25kLWNzdHJzLXRhcmdldC1tdmFyIGFyZyBpbnNuIGJiKQorICAgICAgICAg IGZvciB0YXJnZXQtdmFycyA9IChjb21wLWNvbmQtY3N0cnMtaWRlbnRpY2FsLXZhcnMgKGxpc3Qg YXJnKSBiYiBpbnNuKQogICAgICAgICAgIHVubGVzcyAoY29tcC1jc3RyLXAgY3N0cikKICAgICAg ICAgICAgIGRvIChzaWduYWwgJ25hdGl2ZS1pY2UKICAgICAgICAgICAgICAgICAgICAgICAgKGxp c3QgIkluY29oZXJlbnQgdHlwZSBzcGVjaWZpZXIgZm9yIGZ1bmN0aW9uIiBmKSkKLSAgICAgICAg ICB3aGVuIChhbmQgdGFyZ2V0CisgICAgICAgICAgZG8gKHNldHEgdGFyZ2V0LXZhcnMgKG1hcGNh cgorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAobGFtYmRhIChtdmFyKQorICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIChpZiAoYW5kCisgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAoY29tcC1tdmFyLXAgbXZhcikKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChlcXVhbCAoY29tcC1tdmFyLXNsb3QgbXZhcikKKyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY29tcC1tdmFyLXNsb3Qg bGhzKSkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjb21wLWNzdHIt Y29weSBtdmFyKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbXZhcikpCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldC12YXJzKSkKKyAgICAgICAgICB3 aGVuIChhbmQgdGFyZ2V0LXZhcnMKICAgICAgICAgICAgICAgICAgICAgOzsgTm8gbmVlZCB0byBh ZGQgY2FsbCBjb25zdHJhaW50cyBpZiB0aGlzIGlzIHQKICAgICAgICAgICAgICAgICAgICAgOzsg KGJ1ZyM0NTgxMiBidWcjNDU3MDUgYnVnIzQ1NzUxKS4KLSAgICAgICAgICAgICAgICAgICAgKG5v dCAoZXF1YWwgY29tcC1jc3RyLXQgY3N0cikpCi0gICAgICAgICAgICAgICAgICAgIChvciAobnVs bCBsaHMpCi0gICAgICAgICAgICAgICAgICAgICAgICAobm90IChlcWwgKGNvbXAtbXZhci1zbG90 IGxocykKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY29tcC1tdmFyLXNsb3Qg dGFyZ2V0KSkpKSkKLSAgICAgICAgICAgIGRvIChjb21wLWVtaXQtY2FsbC1jc3RyIHRhcmdldCBp bnNuLWNlbGwgY3N0cikpKSkpKSkKKyAgICAgICAgICAgICAgICAgICAgKG5vdCAoZXF1YWwgY29t cC1jc3RyLXQgY3N0cikpKQorICAgICAgICAgICAgZG8gKGNvbXAtZW1pdC1jYWxsLWNzdHJzIHRh cmdldC12YXJzIGluc24tY2VsbCBjc3RyKSkpKSkpKQogCiAoZGVmdW4gY29tcC1hZGQtY3N0cnMg KF8pCiAgICJSZXdyaXRlIGNvbmRpdGlvbmFsIGJyYW5jaGVzIGFkZGluZyBhcHByb3ByaWF0ZSAn YXNzdW1lJyBpbnNucy4KQEAgLTI1MjksNyArMjY3OCw3IEBAIGNvbXAtYWRkLWNzdHJzCiAgICht YXBoYXNoIChsYW1iZGEgKF8gZikKICAgICAgICAgICAgICAod2hlbiAoYW5kICg+PSAoY29tcC1m dW5jLXNwZWVkIGYpIDEpCiAgICAgICAgICAgICAgICAgICAgICAgICA7OyBObyBwb2ludCB0byBy dW4gdGhpcyBvbiBkeW5hbWljIHNjb3BlIGFzCi0gICAgICAgICAgICAgICAgICAgICAgICA7OyB0 aGlzIHBhc3MgaXMgZWZmZWNpdmUgb25seSBvbiBsb2NhbAorICAgICAgICAgICAgICAgICAgICAg ICAgOzsgdGhpcyBwYXNzIGlzIGVmZmVjdGl2ZSBvbmx5IG9uIGxvY2FsCiAgICAgICAgICAgICAg ICAgICAgICAgICA7OyB2YXJpYWJsZXMuCiAJCQkoY29tcC1mdW5jLWwtcCBmKQogICAgICAgICAg ICAgICAgICAgICAgICAgKG5vdCAoY29tcC1mdW5jLWhhcy1ub24tbG9jYWwgZikpKQo= --000000000000a5273005bbfc4e5e-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 04:04:56 2021 Received: (at 46670) by debbugs.gnu.org; 23 Feb 2021 09:04:56 +0000 Received: from localhost ([127.0.0.1]:58298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lETcm-0003AD-3J for submit@debbugs.gnu.org; Tue, 23 Feb 2021 04:04:56 -0500 Received: from mx.sdf.org ([205.166.94.24]:59078) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lETck-0003A5-Ec for 46670@debbugs.gnu.org; Tue, 23 Feb 2021 04:04:55 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11N94lfD019899 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 23 Feb 2021 09:04:48 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Tue, 23 Feb 2021 09:04:46 +0000 In-Reply-To: (Pip Cet's message of "Tue, 23 Feb 2021 07:59:32 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Mon, Feb 22, 2021 at 1:12 PM Andrea Corallo wrote: >> Good catch thanks! :) Should be fixed by d6227f6edc. > > I'm also confused by the use of NEGATED in comp-emit-assume: if RHS is > a constraint, it emits the complementary constraint. > > However, the code in comp-add-cond-cstrs uses NEGATED to express a > much weaker constraint: that two mvars aren't strictly equal. > > If x /= y and y in SET, we can't conclude that x not in SET (unless > SET is a singleton, an important special case). > > So it all works right now because emit-assume NEGATED=t RHS=mvar means > "LHS isn't equal to RHS" but NEGATED=t RHS=cstr means "LHS can't > satisfy RHS". > > My code changed the call to pass a constraint instead of the mvar, and > then things broke :-) > > We should be consistent about what NEGATED means, I think. > > But apart from such problems, my code appears to be working. I'm > attaching it for the sake of completeness, not because I expect you to > read it all before it's cleaned up. Hi Pip thanks for the patch, the approach of adding a cstr directly in the assume works for this case but is not generic as referencing there an mvar. The reason is that a later run of fw-prop after add-cstrs might be able to prove more precisely what the mvar is if the code was morphed in the meanwhile by some other pass. This in contrast with adding a cstr that being "written into the stone" will stay as such no matter what. Admittedly ATM the only pass rewriting some code after assumes are placed and before the last fw-prop is run is 'tco' so this might be a real case only for functions affected by this, but in the future we may (and most likely want to) have more passes in that position of the compiler pipeline. So yeah I still prefer to general approach of keeping an mvar live till there and referencing it in the assume so that any future propagation within the SSA lattice can update this. Yesterday evening I did some work in that direction, doesn't look too invasive or complex. I'll finish it this week as soon as I've some more time to put into. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 04:08:11 2021 Received: (at 46670) by debbugs.gnu.org; 23 Feb 2021 09:08:11 +0000 Received: from localhost ([127.0.0.1]:58306 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lETfu-0003FE-Mi for submit@debbugs.gnu.org; Tue, 23 Feb 2021 04:08:11 -0500 Received: from mail-ot1-f41.google.com ([209.85.210.41]:41253) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lETfs-0003Ev-Aj for 46670@debbugs.gnu.org; Tue, 23 Feb 2021 04:08:08 -0500 Received: by mail-ot1-f41.google.com with SMTP id s107so14854259otb.8 for <46670@debbugs.gnu.org>; Tue, 23 Feb 2021 01:08:08 -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=5jC+r8DckbjYY7/MEabjU9b/H7fJpZgkGaZPQveNDpI=; b=sBDPgVR1i1cyAG5gwViEUpHZovYkAJ/TPFh9vG1Zw9GHJ76s1jbWZP//mI48OQZpdI pm4yJ5FXZvYrd8PI3lNaW95GN/3YMLsga8wY7WP7LPxUo1v5ALl+EtzdWQvycjb3zdxT EqyR9jhXqO8MHASX21i7feeUDVC2lUpJ6PEWe9lBqDJj6tpoAq5dMCsZK52/iWaTNX25 B1y3DZWVigsAzTUw4VjAk3wka5tW4vH3WTuagtUgJBkuHDsYnpOrJiHtJ9UeT3gAGWoq uLZGWmfJQ66RCjoy3CcuO/cUxzLacJ0wYuwOrcdz1DBTsKpSzWJgk9/M2gaH2gch10Da cTZA== 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=5jC+r8DckbjYY7/MEabjU9b/H7fJpZgkGaZPQveNDpI=; b=HjYvPfEr1AFTVowWcBe1LSYdoo1FsyQwQcOXmuw6I+e3ktYMtKLdmU2hP0P0HRV2Up Lv9L/jp+swpYEBtiEgKLypqHEo7mkPLq5pK0Ij4L3NvMybvyAoE9O1VqcELw99YR6wHD nAJZDGIsS+5SLYU9BIp5Uac8qv4K1WY3iWvWNivSNQ3htw4hwMS41mYC7jgVQ7opDIND ycJx0PAfnrb9256i+GFG6OPI8N4X4CpEJPCP/LeZS+mx2RCfTalvqQC+gkrau6sLdN9q FMf0aJl6NN+L0klbx6tDe6TN0phMJYIQhf1GHToJ0G9GEEdncNmca/LBhzrJwB9gy3Z2 iU3w== X-Gm-Message-State: AOAM5328/mzGTguhsKzDbul7JwAc05gCqYrW+Pvj/BEEBcz0zs5DqK76 O8QJ6z8JYE2GmPFlq4/BgYMkKBiPB3Iu9KyzkKw= X-Google-Smtp-Source: ABdhPJxY5e2/QyC47dAFphhZjYAbuGWYygZHlNXONzQpe8GJw+8dolMXwf9vVUavr5EGOKekg04aOSb+fxtSap/VzPc= X-Received: by 2002:a05:6830:1605:: with SMTP id g5mr19739007otr.292.1614071282780; Tue, 23 Feb 2021 01:08:02 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Tue, 23 Feb 2021 09:07:26 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Feb 22, 2021 at 11:16 AM Andrea Corallo wrote: > Pip Cet writes: > >> Yes but in this case (and probably others) we *have* to emit this > >> assumption. > > > > Why? Are you saying the compiler requires (assume ...) insns for > > correctness? If it does, I'm afraid that's a serious issue. > > It requires that assume if we want to infer precisely here. If we > give-up emitting this assume it will just works perfectly but we'll miss > to predict the return value as we should. Emitting an assumption about a dead variable only makes sense if the dead variable matches a live one. And in that case, we can just emit the assumption about the live variable to begin with. > > Again, that does seem very complicated, and if it improves > > optimization we could probably improve it much more by modifying the > > byte compiler to pop arguments in the caller rather than the callee. > > To me this sounds considerably more invasive, probably is because I'm > much more used to work with the native compiler code that with the byte > compiler one :) That is a little more invasive, but it's where you're going if you make the major change of allocating your own stack slots rather than letting the byte compiler do it. > I like the idea of the native compiler patch being less invasive as > possible, this was the line I tried to follow and I think so far it > paid. I guess a number of readers would'd agree with this kind of > approach to begin with. I agree with it! That's why "leave slot allocation to the byte compiler" is something I don't want you to throw away unnecessarily, because it's a great simplifying assumption. > I think I should be able to work it out as discussed in one two evenings > and it might be useful for other cases in the future too, so it does not > sound as a big deal to me. It does to me, I must say. There's nothing special about comparisons: you're turning a = a OP b two-operand code into c = a OP b three-operand code. Your code won't be as good as genuine three-operand code, and it won't be as simple as two-operand code. > >> > In fact, all we need to do is tell comp-cond-cstrs-target-mvar to > >> > return nil more often, isn't it? > >> > >> Nope, the target mvar identified is the correct one, we just have ATM no > >> way to reference it reliably into the assume. > > > > We don't have to, let's just not emit an assume about a variable that > > we just introduced and that's never read? > > We disagree :) We can disagree about the "let's" part (and should, of course), but we should agree about the "we don't have to" part, because that's a matter of fact, not opinion. > As the byte compiler does not care about propagating types and values it > can just clobber the variable, here we aim for more so we need it to > keep it live till the assume. If we decide the variable needs to be kept live, the byte compiler should keep it live, not us. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 14:09:56 2021 Received: (at 46670) by debbugs.gnu.org; 23 Feb 2021 19:09:56 +0000 Received: from localhost ([127.0.0.1]:60514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEd4F-0003ge-SE for submit@debbugs.gnu.org; Tue, 23 Feb 2021 14:09:56 -0500 Received: from mail-oi1-f173.google.com ([209.85.167.173]:37123) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEd4D-0003gR-TZ for 46670@debbugs.gnu.org; Tue, 23 Feb 2021 14:09:54 -0500 Received: by mail-oi1-f173.google.com with SMTP id l133so10506446oib.4 for <46670@debbugs.gnu.org>; Tue, 23 Feb 2021 11:09:53 -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=qqjwJ9E/2KKFjgVHPVGbQgHlU7sfqVfAa196XpJPU2o=; b=nZtjohSlAPtX5VVumDfboHk9ETPCZnyrvL5Pwz8RyiXtFeDP35jgX9OCBqZNa5lvBG Pu5x1jGtL41kpxLbEvI0KjHOBsYx4tMDBvoIYkV/6j4r0pXHqb3hJUTgHvbgeIHu001U E3Lha5YSMy3R+3Qzv9GIkWFj/joW7jCJb/T0LZoB+tLurvzrnLrcZD3Ne9jXGwaegjo5 mXUK/3X2SVEyFNQ77+3DBNRw6AUm8Az7eibarKDXHIKsu3bveZk+yLL63agI1qlOTAKU lUlG/LyCQC4pChf5jP91A/VGS57JDkrHRIn2XJ9zzvcTKhQgbfPJ/m4MHVODImiMQNSw 4Ehg== 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=qqjwJ9E/2KKFjgVHPVGbQgHlU7sfqVfAa196XpJPU2o=; b=SOMMefqkCxWDFXP1dTx9bjrqrUoah9bQxem8hUlA4djTnyTQ07EajmdGKomxoTdD5B J6RlPUhsB3L1S3imSMIfAlQS0hPvY1Rwgdzxd2aKJAO2zg608yOgvkP0HaP6gV98J1tN tkfxj4Iw6vg2Q8Sml1XZSyOh++QM1J+jKq44zBqcFk6rCrPLcY5u5eGCXHa+lLCNPuYo cm3rGG8/b6ZEBTnRrPb9YgrnZZH4xpnX5bKjFYWB7sSoOqCesPcsC2U3EZRnzQm8f1b2 xpZd+mj8ibuwIH6azZ0T0qfYiPdDqXMdU5U9GXn6VbalH8VWEU3aci2ypROpe/9d5ZrK BLnA== X-Gm-Message-State: AOAM530JVlulAphOBgrh+U4yyWxvTIHi/hWoQVjg7Ckt0PmaXC/1ZHLf b7Xw4+JvxEqkClO9e8NbsMzbWuRjQwk+frzaCxA= X-Google-Smtp-Source: ABdhPJzL9mMyAjJOc7YXOcTV4Eu+CyTChqVn7HDgnH/MPXTMNvxGg4DJjw6SbTLiKjWjSactWFJp3x7SywzxGkgFjPo= X-Received: by 2002:aca:6141:: with SMTP id v62mr206196oib.30.1614107388401; Tue, 23 Feb 2021 11:09:48 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Tue, 23 Feb 2021 19:09:11 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: multipart/mixed; boundary="00000000000083f9b005bc05a99b" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000083f9b005bc05a99b Content-Type: text/plain; charset="UTF-8" On Mon, Feb 22, 2021 at 1:12 PM Andrea Corallo wrote: > We'll probably see other bugs in this area cause is tricky, is important > we build the best coverage we can for this in the testsuite. Is this one of them, or am I confused? --00000000000083f9b005bc05a99b Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Don-t-emit-incorrect-assumptions-for-non-equality-Bu.patch" Content-Disposition: attachment; filename="0001-Don-t-emit-incorrect-assumptions-for-non-equality-Bu.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_klidt3xy0 RnJvbSA5YWIzYTFlODE5NmNjZTEwZWFiNTA5MDMzMDJhZjFjYzI0NTgwNTk1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBUdWUs IDIzIEZlYiAyMDIxIDE5OjA1OjUzICswMDAwClN1YmplY3Q6IFtQQVRDSF0gRG9uJ3QgZW1pdCBp bmNvcnJlY3QgYXNzdW1wdGlvbnMgZm9yIG5vbi1lcXVhbGl0eSAoQnVnIzQ2NzcwKQoKKiBsaXNw L2VtYWNzLWxpc3AvY29tcC5lbCAoY29tcC1hZGQtY29uZC1jc3Rycyk6IERvbid0IGFzc3VtZSB0 aGUKbGhzIGFuZCByaHMgY29pbmNpZGUgZm9yIGEgbmVnYXRlZCAnYW5kIGNvbnN0cmFpbnQuCi0t LQogbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwgfCA0ICsrLS0KIDEgZmlsZSBjaGFuZ2VkLCAyIGlu c2VydGlvbnMoKyksIDIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9lbWFjcy1saXNw L2NvbXAuZWwgYi9saXNwL2VtYWNzLWxpc3AvY29tcC5lbAppbmRleCA2MGMwNDA5MjZlNTRjLi44 NDdjNWM0MjRhYWE4IDEwMDY0NAotLS0gYS9saXNwL2VtYWNzLWxpc3AvY29tcC5lbAorKysgYi9s aXNwL2VtYWNzLWxpc3AvY29tcC5lbApAQCAtMjI1NSw4ICsyMjU1LDggQEAgY29tcC1lbWl0LWFz c3VtZQogICAgICAgKCdhbmQKICAgICAgICAoaWYgKGNvbXAtbXZhci1wIHJocykKICAgICAgICAg ICAgKGxldCAoKHRtcC1tdmFyIChpZiBuZWdhdGVkCi0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKG1ha2UtY29tcC1tdmFyIDpzbG90IChjb21wLW12YXItc2xvdCByaHMpKQotICAgICAg ICAgICAgICAgICAgICAgICAgICAgICByaHMpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAobWFrZS1jb21wLW12YXIgOnNsb3QgKGNvbXAtbXZhci1zbG90IGxocykpCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGxocykpKQogICAgICAgICAgICAgIChwdXNoIGAoYXNzdW1l ICwobWFrZS1jb21wLW12YXIgOnNsb3QgbGhzLXNsb3QpCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgKGFuZCAsbGhzICx0bXAtbXZhcikpCiAJICAgICAgICAgICAoY29tcC1ibG9jay1pbnNu cyBiYikpCi0tIAoyLjMwLjAKCg== --00000000000083f9b005bc05a99b-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 17:55:14 2021 Received: (at 46670) by debbugs.gnu.org; 23 Feb 2021 22:55:14 +0000 Received: from localhost ([127.0.0.1]:60876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEgaH-000358-Q6 for submit@debbugs.gnu.org; Tue, 23 Feb 2021 17:55:14 -0500 Received: from mx.sdf.org ([205.166.94.24]:56610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEgaF-00034x-Eg for 46670@debbugs.gnu.org; Tue, 23 Feb 2021 17:55:12 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11NMt6tX013471 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 23 Feb 2021 22:55:06 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Tue, 23 Feb 2021 22:55:06 +0000 In-Reply-To: (Pip Cet's message of "Tue, 23 Feb 2021 09:07:26 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Mon, Feb 22, 2021 at 11:16 AM Andrea Corallo wrote: >> Pip Cet writes: >> >> Yes but in this case (and probably others) we *have* to emit this >> >> assumption. >> > >> > Why? Are you saying the compiler requires (assume ...) insns for >> > correctness? If it does, I'm afraid that's a serious issue. >> >> It requires that assume if we want to infer precisely here. If we >> give-up emitting this assume it will just works perfectly but we'll miss >> to predict the return value as we should. > > Emitting an assumption about a dead variable only makes sense if the > dead variable matches a live one. And in that case, we can just emit > the assumption about the live variable to begin with. > >> > Again, that does seem very complicated, and if it improves >> > optimization we could probably improve it much more by modifying the >> > byte compiler to pop arguments in the caller rather than the callee. >> >> To me this sounds considerably more invasive, probably is because I'm >> much more used to work with the native compiler code that with the byte >> compiler one :) > > That is a little more invasive, but it's where you're going if you > make the major change of allocating your own stack slots rather than > letting the byte compiler do it. > >> I like the idea of the native compiler patch being less invasive as >> possible, this was the line I tried to follow and I think so far it >> paid. I guess a number of readers would'd agree with this kind of >> approach to begin with. > > I agree with it! That's why "leave slot allocation to the byte > compiler" is something I don't want you to throw away unnecessarily, > because it's a great simplifying assumption. > >> I think I should be able to work it out as discussed in one two evenings >> and it might be useful for other cases in the future too, so it does not >> sound as a big deal to me. > > It does to me, I must say. There's nothing special about comparisons: > you're turning a = a OP b two-operand code into c = a OP b > three-operand code. Your code won't be as good as genuine > three-operand code, and it won't be as simple as two-operand code. > >> >> > In fact, all we need to do is tell comp-cond-cstrs-target-mvar to >> >> > return nil more often, isn't it? >> >> >> >> Nope, the target mvar identified is the correct one, we just have ATM no >> >> way to reference it reliably into the assume. >> > >> > We don't have to, let's just not emit an assume about a variable that >> > we just introduced and that's never read? >> >> We disagree :) > > We can disagree about the "let's" part (and should, of course), but we > should agree about the "we don't have to" part, because that's a > matter of fact, not opinion. This new mvar *is* used, actually by an assume. And the assume in discussion is targetting a live variable that will be used by functional code so I really see no scandal here. >> As the byte compiler does not care about propagating types and values it >> can just clobber the variable, here we aim for more so we need it to >> keep it live till the assume. > > If we decide the variable needs to be kept live, the byte compiler > should keep it live, not us. Again no, any pass in the compiler must have the right to create new temporaries for whichever purpose it wants, and indeed we can't expect the byte-compiler to know in advance all passes in the native compiler and their scopes and goals. `add-cstrs' is just the first pass that now happen to have this need, is not a special case of any sort. Not giving the possibilities to passes to create variables would be totally equivalent to prevent GIMPLE passes in GCC to create new local variables while performing transformations, it would be ludicrous and this is just something we *want* to be able to do. Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 18:26:36 2021 Received: (at 46670) by debbugs.gnu.org; 23 Feb 2021 23:26:36 +0000 Received: from localhost ([127.0.0.1]:60923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEh4d-0003rt-OT for submit@debbugs.gnu.org; Tue, 23 Feb 2021 18:26:35 -0500 Received: from mx.sdf.org ([205.166.94.24]:54655) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEh4b-0003rj-81 for 46670@debbugs.gnu.org; Tue, 23 Feb 2021 18:26:34 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11NNQPXN006778 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 23 Feb 2021 23:26:25 GMT From: Andrea Corallo To: Mauricio Collares Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Tue, 23 Feb 2021 23:26:25 +0000 In-Reply-To: (Andrea Corallo via's message of "Tue, 23 Feb 2021 09:04:46 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Pip Cet X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: [...] > Hi Pip thanks for the patch, > > the approach of adding a cstr directly in the assume works for this case > but is not generic as referencing there an mvar. > > The reason is that a later run of fw-prop after add-cstrs might be able > to prove more precisely what the mvar is if the code was morphed in the > meanwhile by some other pass. This in contrast with adding a cstr that > being "written into the stone" will stay as such no matter what. > > Admittedly ATM the only pass rewriting some code after assumes are > placed and before the last fw-prop is run is 'tco' so this might be a > real case only for functions affected by this, but in the future we may > (and most likely want to) have more passes in that position of the > compiler pipeline. > > So yeah I still prefer to general approach of keeping an mvar live till > there and referencing it in the assume so that any future propagation > within the SSA lattice can update this. > > Yesterday evening I did some work in that direction, doesn't look too > invasive or complex. I'll finish it this week as soon as I've some more > time to put into. > > Thanks > > Andrea Right I've pushed bddd7a2d13 implementing the discussed solution as I'm convinced is more general and future proof. The patch is passing the tests and bootstrapping clean, also is adding a test that should cover this specific bug. Mauricio could you verify it actually solves the lsp-mode issue? Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 18:36:11 2021 Received: (at 46670) by debbugs.gnu.org; 23 Feb 2021 23:36:12 +0000 Received: from localhost ([127.0.0.1]:60927 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEhDv-00046I-NK for submit@debbugs.gnu.org; Tue, 23 Feb 2021 18:36:11 -0500 Received: from mx.sdf.org ([205.166.94.24]:54167) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEhDt-000469-BN for 46670@debbugs.gnu.org; Tue, 23 Feb 2021 18:36:09 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11NNa2fU013829 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 23 Feb 2021 23:36:03 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Tue, 23 Feb 2021 23:36:02 +0000 In-Reply-To: (Pip Cet's message of "Tue, 23 Feb 2021 19:09:11 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Mon, Feb 22, 2021 at 1:12 PM Andrea Corallo wrote: >> We'll probably see other bugs in this area cause is tricky, is important >> we build the best coverage we can for this in the testsuite. > > Is this one of them, or am I confused? What's suspitions with that? At present I'm admittedly quite done but it looks okay to me. BTW applying the patch and running comp-tests.el I get 39 regressions. Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 21:10:51 2021 Received: (at 46670) by debbugs.gnu.org; 24 Feb 2021 02:10:51 +0000 Received: from localhost ([127.0.0.1]:32897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEjdb-00080d-1c for submit@debbugs.gnu.org; Tue, 23 Feb 2021 21:10:51 -0500 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:42507) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEjdZ-00080G-3k for 46670@debbugs.gnu.org; Tue, 23 Feb 2021 21:10:49 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 354C5C9A; Tue, 23 Feb 2021 21:10:43 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 23 Feb 2021 21:10:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=collares.org; h= date:from:to:cc:subject:in-reply-to:references:message-id :mime-version:content-type:content-transfer-encoding; s=fm2; bh= CTKYCXcQRnMfpyCn9gJoOwp+Mc/iecfTfTQ/43B78L4=; b=LKC7ntfNEtotbO80 nrcdgR4d22mHuYowG60LR6rDavCgDscvPJDP+nQeOGiaWf+TrsibLAMS5S7tQoQf a+gTbuvLvjoutKdSJw3vt1M0HdgmWgsfJK0983fgndF+WzjzREakzmj75DBenV3T mvYCcDxfaNZ1eMloyyTiFdLeOnDsm17jDnbErzCi/bjT/mmKl6Eq2vnKOdARUzvM kpTTTkoiXE/zKfha45J4F45UKIVno912GFT7Wizt3X6rVkB8YWP9tknuzXUr5J1o A/CoBqpOFBI4eJKl8Z4Coc/AfpFETNLUUpAZt3oFi4n+2yB7lznEwRg/6k83zFE/ /zQG0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=CTKYCXcQRnMfpyCn9gJoOwp+Mc/iecfTfTQ/43B78 L4=; b=cd5J6nbeABZHIYZ4Gq3uiPtYOkD4VMiqmdk9Ft7LiJBA34TWr0qQInLYS lkGDoYyOJSBJ8ZaobKtje51lCAnHyyhKXVNRXYDeaYmIzOyOesFoOH3CIlLiIlu/ +AVYyHbveyumLI4WdM8K5hTOqbPUrCDRzt1/oYV3X7oQ8vuv9laweojzThBXUWq7 6Ngq+ZYQ3ClMNZTamEKG1mqLrK5tOitA1LZnIqvT6s78eKHK/4OswGnrnW4DRPfe DAJJEs703B+bhPB2WlHSEbSgWRA4NPbtfkdImf3JkX+9RlD56rgEloCYSf7YJLFn uYlJ1mgY9PovjYTw+Ah0rqx95EwEQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeeigdeflecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffufggjfhfkgggtgfesthhqmh dttderjeenucfhrhhomhepofgruhhrihgtihhoucevohhllhgrrhgvshcuoehmrghurhhi tghiohestgholhhlrghrvghsrdhorhhgqeenucggtffrrghtthgvrhhnpefgueetlefgge egvddvveefieeiffetjeefkedvvdehffdtvddvteefudekhfduteenucfkphepudeluddr udekhedrfeegrddvudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhgruhhrihgtihhosegtohhllhgrrhgvshdrohhrgh X-ME-Proxy: Received: from [127.0.0.1] (unknown [191.185.34.215]) by mail.messagingengine.com (Postfix) with ESMTPA id D53AB240054; Tue, 23 Feb 2021 21:10:40 -0500 (EST) Date: Tue, 23 Feb 2021 23:10:37 -0300 From: Mauricio Collares To: Andrea Corallo Subject: =?US-ASCII?Q?Re=3A_bug=2346670=3A_28=2E0=2E50=3B_=5Bfeature/native-comp?= =?US-ASCII?Q?=5D_possible_miscompilation_affecting_lsp-mode?= User-Agent: K-9 Mail for Android In-Reply-To: References: <87a6ry46uc.fsf@collares.org> Message-ID: <41A7618F-251C-4D99-B7A9-05D479676AED@collares.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) On February 23, 2021 8:26:25 PM GMT-03:00, Andrea Corallo = wrote: >Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of >text editors" writes: > >Right I've pushed bddd7a2d13 implementing the discussed solution as I'm >convinced is more general and future proof=2E > >The patch is passing the tests and bootstrapping clean, also is adding a >test that should cover this specific bug=2E > >Mauricio could you verify it actually solves the lsp-mode issue? Hi Andrea, I've verified that the lsp-mode completion issue is fixed=2E Many, many th= anks!=20 By the way, I just noticed that this is probably the same issue that was r= eported by X L and =C3=93scar Fuentes in emacs-devel ('Completion doesn't s= tart after "=2E" Is pressed in go-mode with gopls')=2E Best, Mauricio From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 23:32:42 2021 Received: (at 46670) by debbugs.gnu.org; 24 Feb 2021 04:32:42 +0000 Received: from localhost ([127.0.0.1]:33042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lElqs-00032x-8U for submit@debbugs.gnu.org; Tue, 23 Feb 2021 23:32:42 -0500 Received: from mail-ot1-f54.google.com ([209.85.210.54]:39767) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lElqo-00032g-7B for 46670@debbugs.gnu.org; Tue, 23 Feb 2021 23:32:40 -0500 Received: by mail-ot1-f54.google.com with SMTP id h22so982141otr.6 for <46670@debbugs.gnu.org>; Tue, 23 Feb 2021 20:32:38 -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=0J0lyHL52Tq5d1Qt2/Urt5up7gDJ2mBcCCrWDeyYVek=; b=vJokhuDY2kpFDbPrfRHXD7NgNJ3ENEwSVty5e7aMcONBo4AvaAiKjiiVldAW3RgTcS cWU96xarM2vDoPigo2vOiwmAYQA2BjWo54UUlQilbC7fJOVAl/WDqtQK/Yk2mYr9frNE 0xP4QgYvSHbJPoB86pAJfb8n1F0s4nlazQ+gPNgCkBzfCAxshO1Kbgk0ZQ7WMxrnsejn uRomivef/EECCCy/FBVVPOrPjz2D9UAxasLPKzmyFSoQNzRts/pm9QHzeTQn83cQBj/5 2FL6KckEy/0lUZ+liTG7iq7k6YvSCuxPTCpawC/1nN+7hQdQMedGWgn4WygqIhEIUMih jLEg== 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=0J0lyHL52Tq5d1Qt2/Urt5up7gDJ2mBcCCrWDeyYVek=; b=cVf9/eHV4sh/K+LRpkex07m8m/1cSkSRYYX1RO96q/KxEKGXmR81ggZ9TBXgbSKHu3 Hqn9VFWqaKdgsfTsEncaOzc/ptLHyT1fxAoFwmQ2gjmhGa5zUv16Vaa0z4b2Aq/JU275 afTf9Tnnln011vtVmcNh0RxEi2HXREIoLwfz2We49YqbNjlrMSW8FnvZhlznxaWddAn1 ZYIWRyzcStpB26VtG7aYGoFX9oXXuTsBbPYqGWMXovez9m5aJfl/eIw+LRAqWuiTS9a8 Pzt/QDIqXzi+Yg5KQ5zdvI+oMOCQo+4vSiwRWqozoTDZS4nN4MNXD/kuczwSFcekdRGm bi2Q== X-Gm-Message-State: AOAM531VV/WlAkn1jUTRD9d6OInQBkMXpJ577h+xhq1IqRQLzoNb1yGB 452NX0naN4iMCCEdjSMfC7RglOFHgzYwG3fycXs= X-Google-Smtp-Source: ABdhPJxNmeeeTbfaJpXZopS4oBvbvvKKR/+xr7NSsmbaKyQg6hNDGlSTBoCVB3zynP22NQWV+rLn9vyROuKrM4bIT8o= X-Received: by 2002:a9d:131:: with SMTP id 46mr1861536otu.287.1614141152463; Tue, 23 Feb 2021 20:32:32 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Wed, 24 Feb 2021 04:31:56 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Feb 23, 2021 at 11:36 PM Andrea Corallo wrote: > Pip Cet writes: > > > On Mon, Feb 22, 2021 at 1:12 PM Andrea Corallo wrote: > >> We'll probably see other bugs in this area cause is tricky, is important > >> we build the best coverage we can for this in the testsuite. > > > > Is this one of them, or am I confused? > > What's suspitions with that? At present I'm admittedly quite done but > it looks okay to me. We're emitting (assume ,lhs (and ,lhs ,rhs)) even when NEGATED is t. > BTW applying the patch and running comp-tests.el I get 39 regressions. That's expected, because we need to replace the incorrect assume by correct ones to actually get to the same level of optimization. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 24 02:01:08 2021 Received: (at 46670) by debbugs.gnu.org; 24 Feb 2021 07:01:08 +0000 Received: from localhost ([127.0.0.1]:33171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEoAV-0006jW-Qx for submit@debbugs.gnu.org; Wed, 24 Feb 2021 02:01:08 -0500 Received: from mail-oi1-f177.google.com ([209.85.167.177]:33976) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEoAS-0006iu-3t for 46670@debbugs.gnu.org; Wed, 24 Feb 2021 02:01:06 -0500 Received: by mail-oi1-f177.google.com with SMTP id w69so1472013oif.1 for <46670@debbugs.gnu.org>; Tue, 23 Feb 2021 23:01:04 -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=mGPvdUdi9J3vmPX/bIxDtos8SdMZZ7HNYylFkXRS+6c=; b=pif3mWdLpqh+jLeXM69v4i0BGdLguDZYUtGj2DaSo0THxWoOCSsHtuyhbJHxxSAD0H c8zOFXtyVSopG/a3mnv6FVRU/FMdasyq6VMtmgUWJAZSDoedJwQZYKhmzskjiU/Xnht3 3Z7m02VhH5P91ZlW8jEpVI5VRriDx35Yn8GMAtz+PJU2XM4cY8P8f0x97ohOT6gi0WcX FLTiywargLxm+wj+rZgn9EBM857OhbKY2srFO2zj5QtnizM13TQCL9cTYaV9V7IC0AyD /HqWCWOOm588cZ52wjY2LAVvUjPyoJwSgRedfgUsHsPGwXjkTumYsGnAp9YvvPdNPtoN zNbQ== 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=mGPvdUdi9J3vmPX/bIxDtos8SdMZZ7HNYylFkXRS+6c=; b=Rxn46lvZLm+EFxrdjjoxQv40Wbk2PvTReDiaO80zC+e9D2TtvR/i7NaHoMzQcEEJvA wDBSc/4fKWr+1oPIT8V0QsEPm3xWY8xxe1PloyVtbW54C/3R07jtSQ3DazC62yczr6vg mecqmsGsLM7bfWulHhxzn67CYwYyrtkVrz+BlhE4Igw+gd096TBhAaVln09Gl6oajx7V ebhGB2zsPncfj7//Or7ot4GhP0/y9S/eciFF+ZmesXgzxOKdMmnl+KGkb/6X3UOVmXA2 +IGM5kDu8YAqABI3jMuciP331W8X38g8L+5Hd8agrci1nsD02XDsbwlJMLFtJYQVLNQu sqRQ== X-Gm-Message-State: AOAM532RafM+N7yn1WUdHBMdXNoffdjhxzXWvN3FMI2Hp7rmjZiMoKO8 RVC50cbzbILDflEkaNy2n8QR7AYfPTazftdDzkA= X-Google-Smtp-Source: ABdhPJy/PElucWV6/SM8r2FtPvv6wnk51Oyy4PpU7h+uQJj4LgLa78r8B0dpM1Ss0z6s3HIBgz+voNeljwyJfZBSE0A= X-Received: by 2002:a05:6808:8e1:: with SMTP id d1mr1849669oic.122.1614150058349; Tue, 23 Feb 2021 23:00:58 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Wed, 24 Feb 2021 07:00:22 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: multipart/mixed; boundary="000000000000d7b12005bc0f9856" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000d7b12005bc0f9856 Content-Type: text/plain; charset="UTF-8" Hello Andrea, by the way, I'm mostly still pursuing it because it keeps flushing out bugs in comp.el :-) I'm attaching another one, though I'm not sure the bug in question can actually be triggered without modifying the byte compiler. On Tue, Feb 23, 2021 at 10:55 PM Andrea Corallo wrote: > Pip Cet writes: > >> >> > We don't have to, let's just not emit an assume about a variable that > >> > we just introduced and that's never read? > >> > >> We disagree :) > > > > We can disagree about the "let's" part (and should, of course), but we > > should agree about the "we don't have to" part, because that's a > > matter of fact, not opinion. > > This new mvar *is* used, actually by an assume. I said it was never read, which I agree is more correct. > And the assume in > discussion is targetting a live variable that will be used by functional > code so I really see no scandal here. Only on one side of the assume. The other side holds a new "temporary" variable which is assumed to be equal to something that it isn't actually equal to, and that seems very scandalous to me. > >> As the byte compiler does not care about propagating types and values it > >> can just clobber the variable, here we aim for more so we need it to > >> keep it live till the assume. > > > > If we decide the variable needs to be kept live, the byte compiler > > should keep it live, not us. > > Again no, any pass in the compiler must have the right to create new > temporaries for whichever purpose it wants, and indeed we can't expect I agree with that part, by the way. We should, at some point in the future when we need it, add the ability to introduce temporary variables (and remove them), in a clean, well-considered fashion. At present, we don't need it, we lack the ability to remove such variables, and I'm afraid the last parts can be disputed, too. --000000000000d7b12005bc0f9856 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Fix-ICE-when-compiling-an-explicit-call-to-single-ar.patch" Content-Disposition: attachment; filename="0001-Fix-ICE-when-compiling-an-explicit-call-to-single-ar.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_klj38la80 RnJvbSBmNzVlODc0ZDUwYTJlMjJhOWZmOWRmMmZjYmZiZjVlNzRkNmJiZmY1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBXZWQs IDI0IEZlYiAyMDIxIDA2OjU4OjI0ICswMDAwClN1YmplY3Q6IFtQQVRDSF0gRml4IElDRSB3aGVu IGNvbXBpbGluZyBhbiBleHBsaWNpdCBjYWxsIHRvIHNpbmdsZS1hcmd1bWVudAogYC0nCgoqIGxp c3AvZW1hY3MtbGlzcC9jb21wLmVsIChjb21wLWZ3cHJvcC1jYWxsKTogSGFuZGxlCm5lZ2F0aW9u IGFzIHdlbGwgYXMgc3VidHJhY3Rpb24uCi0tLQogbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwgfCAy ICstCiAxIGZpbGUgY2hhbmdlZCwgMSBpbnNlcnRpb24oKyksIDEgZGVsZXRpb24oLSkKCmRpZmYg LS1naXQgYS9saXNwL2VtYWNzLWxpc3AvY29tcC5lbCBiL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVs CmluZGV4IDYwYzA0MDkyNmU1NGMuLjI5ODA2MDViZjg4MDQgMTAwNjQ0Ci0tLSBhL2xpc3AvZW1h Y3MtbGlzcC9jb21wLmVsCisrKyBiL2xpc3AvZW1hY3MtbGlzcC9jb21wLmVsCkBAIC0zMDQwLDcg KzMwNDAsNyBAQCBjb21wLWZ3cHJvcC1jYWxsCiAgICAgICAgICAgICAgIChjb21wLW12YXItbmVn IGx2YWwpIChjb21wLWNzdHItbmVnIGNzdHIpKSkpCiAgICAgKGNsLWNhc2UgZgogICAgICAgKCsg KGNvbXAtY3N0ci1hZGQgbHZhbCBhcmdzKSkKLSAgICAgICgtIChjb21wLWNzdHItc3ViIGx2YWwg YXJncykpCisgICAgICAoLSAoaWYgKGNkciBhcmdzKSAoY29tcC1jc3RyLXN1YiBsdmFsIGFyZ3Mp KSkKICAgICAgICgxKyAoY29tcC1jc3RyLWFkZCBsdmFsIGAoLChjYXIgYXJncykgLGNvbXAtY3N0 ci1vbmUpKSkKICAgICAgICgxLSAoY29tcC1jc3RyLXN1YiBsdmFsIGAoLChjYXIgYXJncykgLGNv bXAtY3N0ci1vbmUpKSkpKSkKIAotLSAKMi4zMC4wCgo= --000000000000d7b12005bc0f9856-- From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 24 03:22:17 2021 Received: (at 46670-done) by debbugs.gnu.org; 24 Feb 2021 08:22:17 +0000 Received: from localhost ([127.0.0.1]:33240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEpR3-0000Av-7C for submit@debbugs.gnu.org; Wed, 24 Feb 2021 03:22:17 -0500 Received: from mx.sdf.org ([205.166.94.24]:50522) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEpR1-0000Al-N5 for 46670-done@debbugs.gnu.org; Wed, 24 Feb 2021 03:22:16 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11O8M8QI012183 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 24 Feb 2021 08:22:09 GMT From: Andrea Corallo To: Mauricio Collares Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> <41A7618F-251C-4D99-B7A9-05D479676AED@collares.org> Date: Wed, 24 Feb 2021 08:22:08 +0000 In-Reply-To: <41A7618F-251C-4D99-B7A9-05D479676AED@collares.org> (Mauricio Collares's message of "Tue, 23 Feb 2021 23:10:37 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670-done Cc: 46670-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Mauricio Collares writes: > On February 23, 2021 8:26:25 PM GMT-03:00, Andrea Corallo = wrote: >>Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of >>text editors" writes: >> >>Right I've pushed bddd7a2d13 implementing the discussed solution as I'm >>convinced is more general and future proof. >> >>The patch is passing the tests and bootstrapping clean, also is adding a >>test that should cover this specific bug. >> >>Mauricio could you verify it actually solves the lsp-mode issue? > > Hi Andrea, > > I've verified that the lsp-mode completion issue is fixed. Many, many tha= nks!=20 > > By the way, I just noticed that this is probably the same issue that > was reported by X L and =C3=93scar Fuentes in emacs-devel ('Completion > doesn't start after "." Is pressed in go-mode with gopls'). Wonderful! I'm closing this bug then. Thank you for reporting it Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 24 04:04:18 2021 Received: (at 46670) by debbugs.gnu.org; 24 Feb 2021 09:04:18 +0000 Received: from localhost ([127.0.0.1]:33281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEq5h-0001JC-Vq for submit@debbugs.gnu.org; Wed, 24 Feb 2021 04:04:18 -0500 Received: from mx.sdf.org ([205.166.94.24]:64668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEq5f-0001Iy-M5 for 46670@debbugs.gnu.org; Wed, 24 Feb 2021 04:04:16 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11O9461O018143 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 24 Feb 2021 09:04:06 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Wed, 24 Feb 2021 09:04:06 +0000 In-Reply-To: (Pip Cet's message of "Wed, 24 Feb 2021 04:31:56 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Tue, Feb 23, 2021 at 11:36 PM Andrea Corallo wrote: >> Pip Cet writes: >> >> > On Mon, Feb 22, 2021 at 1:12 PM Andrea Corallo wrote: >> >> We'll probably see other bugs in this area cause is tricky, is important >> >> we build the best coverage we can for this in the testsuite. >> > >> > Is this one of them, or am I confused? >> >> What's suspitions with that? At present I'm admittedly quite done but >> it looks okay to me. > > We're emitting > > (assume ,lhs (and ,lhs ,rhs)) > > even when NEGATED is t. Nope, when NEGATED is t the complete sequence we are emitting is (see line just following your diff hunk): (assume tmp-mvar (not rhs)) (assume lhs (and lhs tmp-mvar)) That's indeed the reason why it's working in the 39 testcases. Andrea >> BTW applying the patch and running comp-tests.el I get 39 regressions. > > That's expected, because we need to replace the incorrect assume by > correct ones to actually get to the same level of optimization. From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 24 04:29:23 2021 Received: (at 46670) by debbugs.gnu.org; 24 Feb 2021 09:29:24 +0000 Received: from localhost ([127.0.0.1]:33330 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEqTz-0001vn-Ga for submit@debbugs.gnu.org; Wed, 24 Feb 2021 04:29:23 -0500 Received: from mail-ot1-f50.google.com ([209.85.210.50]:44544) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEqTx-0001vX-V6 for 46670@debbugs.gnu.org; Wed, 24 Feb 2021 04:29:22 -0500 Received: by mail-ot1-f50.google.com with SMTP id f33so1521248otf.11 for <46670@debbugs.gnu.org>; Wed, 24 Feb 2021 01:29:21 -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=5jEzuWJRG6cFvPCyq6jFkBRpI4AT6l5qBGpdjGw/Zm8=; b=PgCbhS90AO3TlYyJqhS7DKm+nPCSkIFvHLft7HTAs244kU2B3IM3TJcnoeh3IXuSCG t02jvNOsC/r4+HNoDgVA8Z4BL94gb1vU1WJqlbRGjJltdB4oFf0D7n7ulFNKNCEqRU2/ 4d47WpMsYZUc23Skfk8RSEt6wyYb2n/0l2XShlNiB1yqiB5Y/RDaYRB/vaIekG9kBrj8 QIo93WQbIQrCM6E22/eIq5LsVjHJbG2tfmWZrvi0JKoprFwEw+ef4t9p6Xn4vXKgWgYa 1VnWhVGwYaxsMBjltSDeF9FAQfQZn3CYjU5fjcz38PfZ6WmRyMFR9aM4Ry9dt4WHU//p eisw== 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=5jEzuWJRG6cFvPCyq6jFkBRpI4AT6l5qBGpdjGw/Zm8=; b=R0VhW+2yn4gZRJWsXa/z2bJYw2JVTGIliAr2RSqOHj6FxyrtCxFoam2/MvxDzNXuvd TJ2/zEsFCFerErMxR5l8WxF9F8yR4ibwxn6Y5Nyd5LEuDV+wHn5BVE4f9rvBl/EhROB7 gSCzXTZgxW9aEH2z0jWZJRQEmeJSgepryRVnDHDqb3vZGGA0CGCzIOzd2xAi0vKfMm7e f1ov6XS6NH9JShPQhzUcyNpp7GxIxbsUJ3ynqaKugn/thS+hathFkxjt9AG/4kbM3xqa r3f+XyeHtpiDmma8u7SUmxuN4XkTiemMpSvUH+otg7TKyIpLdwLjn8HMlq/VaNEeiOtF FWiA== X-Gm-Message-State: AOAM533nvMI3PHhMcfHrD25i46YnVt4vMR9l3R59Mjt5aGNiQuBOuehL qHeMKl6zOkmyYSAVRyXE/3F04Blx/5pJEKMVfTM= X-Google-Smtp-Source: ABdhPJxWhVI9h7rzYGUmP56zN6YeaAUJcl2cJaw1rQpaJrJEAizen/zZ7KAvjpICWTCjySzGvPNQTGsxK0oXV6ZohPU= X-Received: by 2002:a05:6830:3090:: with SMTP id f16mr2151126ots.292.1614158956302; Wed, 24 Feb 2021 01:29:16 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Wed, 24 Feb 2021 09:28:39 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: multipart/mixed; boundary="00000000000033c40c05bc11ab1f" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000033c40c05bc11ab1f Content-Type: text/plain; charset="UTF-8" On Wed, Feb 24, 2021 at 9:04 AM Andrea Corallo wrote: > Pip Cet writes: > > > On Tue, Feb 23, 2021 at 11:36 PM Andrea Corallo wrote: > >> Pip Cet writes: > >> > Is this one of them, or am I confused? > >> > >> What's suspitions with that? At present I'm admittedly quite done but > >> it looks okay to me. > > > > We're emitting > > > > (assume ,lhs (and ,lhs ,rhs)) > > > > even when NEGATED is t. > > Nope, when NEGATED is t the complete sequence we are emitting is (see > line just following your diff hunk): > > (assume tmp-mvar (not rhs)) But tmp-mvar is in the same slot as RHS. > (assume lhs (and lhs tmp-mvar)) So this is equivalent (after the next SSA rename) to (assume lhs (and lhs rhs)) > That's indeed the reason why it's working in the 39 testcases. No, the reason it's "working" is that we never assert our assumes. I've got a patch here that does just that :-) --00000000000033c40c05bc11ab1f Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Assert-at-runtime-that-assume-s-assumptions-actually.patch" Content-Disposition: attachment; filename="0001-Assert-at-runtime-that-assume-s-assumptions-actually.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_klj8j4620 RnJvbSA2NDcwYjVlZjI1MDA3ZWNlOGZlYTU3NTRiZWUyMDRlNmI1YmEwMzEyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaXAgQ2V0IDxwaXBjZXRAZ21haWwuY29tPgpEYXRlOiBXZWQs IDI0IEZlYiAyMDIxIDA5OjI1OjQ0ICswMDAwClN1YmplY3Q6IFtQQVRDSF0gQXNzZXJ0IGF0IHJ1 bnRpbWUgdGhhdCBhc3N1bWUncyBhc3N1bXB0aW9ucyBhY3R1YWxseSBob2xkLgoKKiBzcmMvY29t cC5jIChlbWl0X2xpbXBsZV9pbnNuKTogSGFuZGxlIChhc3NlcnQpIGluc25zLgooRmNvbXBfX2Fz c2VydCk6IE5ldyBmdW5jdGlvbi4KKHN5bXNfb2ZfY29tcCk6IE5ldyBkZWZzdWJyIGZvciBhYm92 ZS4KCiogbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwgKGNvbXAtcGFzc2VzKTogQWRkIGBjb21wLWFz c2VydC1hc3N1bWVzJwpwYXNzLgooY29tcC1lbWl0LWFzc2VydCwgY29tcC1hc3NlcnQtYXNzdW1l cy1mdW5jLCBjb21wLWFzc2VydC1hc3N1bWVzKToKTmV3IGZ1bmN0aW9ucy4KLS0tCiBsaXNwL2Vt YWNzLWxpc3AvY29tcC5lbCB8IDQwICsrKysrKysrKysrKysrKysrKysrKysrKwogc3JjL2NvbXAu YyAgICAgICAgICAgICAgfCA2OSArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKwogMiBmaWxlcyBjaGFuZ2VkLCAxMDkgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2xp c3AvZW1hY3MtbGlzcC9jb21wLmVsIGIvbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwKaW5kZXggNjBj MDQwOTI2ZTU0Yy4uZDUzYjg4NzZhYThhZCAxMDA2NDQKLS0tIGEvbGlzcC9lbWFjcy1saXNwL2Nv bXAuZWwKKysrIGIvbGlzcC9lbWFjcy1saXNwL2NvbXAuZWwKQEAgLTE3OCw2ICsxNzgsNyBAQCBj b21wLXBhc3NlcwogICAgICAgICAgICAgICAgICAgICAgICAgY29tcC10Y28KICAgICAgICAgICAg ICAgICAgICAgICAgIGNvbXAtZndwcm9wCiAgICAgICAgICAgICAgICAgICAgICAgICBjb21wLXJl bW92ZS10eXBlLWhpbnRzCisgICAgICAgICAgICAgICAgICAgICAgICBjb21wLWFzc2VydC1hc3N1 bWVzCiAgICAgICAgICAgICAgICAgICAgICAgICBjb21wLWZpbmFsKQogICAiUGFzc2VzIHRvIGJl IGV4ZWN1dGVkIGluIG9yZGVyLiIpCiAKQEAgLTMzODUsNiArMzM4Niw0NSBAQCBjb21wLXJlbW92 ZS10eXBlLWhpbnRzCiAgICAgICAgICAgIChjb21wLWN0eHQtZnVuY3MtaCBjb21wLWN0eHQpKSkK IAogDAorOzs7IEFzc2VydC1hc3N1bWVzIHBhc3Mgc3BlY2lmaWMgY29kZS4KKyhkZWZ1biBjb21w LWVtaXQtYXNzZXJ0IChsaHMgYXNzZXJ0aW9uKQorICAobGV0IChpbnNucykKKyAgICAocGNhc2Ug YXNzZXJ0aW9uCisgICAgICAoKGFuZCAocHJlZCBjb21wLW12YXItcCkpCisgICAgICAgKGxldCAo KGYgYChsYW1iZGEgKHggeSkgKGVxdWFsIHggeSkpKSkKKyAgICAgICAgIChjb21wLWFkZC1jb25z dC10by1yZWxvY3MgZikKKyAgICAgICAgIChwdXNoIGAoYXNzZXJ0ICxmICxsaHMgLGFzc2VydGlv bikgaW5zbnMpKSkKKyAgICAgICgoYW5kIChwcmVkIGNvbXAtY3N0ci1wKSkpCisgICAgICAoYChh bmQgLiAsb3BlcmFuZHMpCisgICAgICAgKGRvbGlzdCAob3Agb3BlcmFuZHMpCisgICAgICAgICAo c2V0cSBpbnNucyAobmNvbmMgaW5zbnMgKGNvbXAtZW1pdC1hc3NlcnQgbGhzIG9wKSkpKSkKKyAg ICAgIChgKG5vdCAsKGFuZCAocHJlZCBjb21wLW12YXItcCkgb3BlcmFuZCkpCisgICAgICAgKGxl dCAoKGYgYChsYW1iZGEgKHggeSkgKG5vdCAoZXF1YWwgeCB5KSkpKSkKKyAgICAgICAgIChjb21w LWFkZC1jb25zdC10by1yZWxvY3MgZikKKyAgICAgICAgIChwdXNoIGAoYXNzZXJ0ICxmICxsaHMg LGFzc2VydGlvbikgaW5zbnMpKSkpCisgICAgaW5zbnMpKQorCisoZGVmdW4gY29tcC1hc3NlcnQt YXNzdW1lcy1mdW5jICgpCisgIChjbC1sb29wCisgICBmb3IgYiBiZWluZyBlYWNoIGhhc2gtdmFs dWUgb2YgKGNvbXAtZnVuYy1ibG9ja3MgY29tcC1mdW5jKQorICAgZG8gKGNvbXAtbG9vcC1pbnNu LWluLWJsb2NrIGIKKyAgICAgICAgKHBjYXNlIGluc24KKyAgICAgICAgICAoYChhc3N1bWUgLChh bmQgKHByZWQgY29tcC1tdmFyLXApIGxocykKKyAgICAgICAgICAgICAgICAgICAgLHJocykKKyAg ICAgICAgICAgKGxldCAoKGYgYChsYW1iZGEgKHggeSkgKG5vdCAoZXF1YWwgeCB5KSkpKSkKKyAg ICAgICAgICAgICAoY29tcC1hZGQtY29uc3QtdG8tcmVsb2NzIGYpCisgICAgICAgICAgICAgKHNl dGYgKGNkciBpbnNuLWNlbGwpCisgICAgICAgICAgICAgICAgICAgKG5jb25jIChjb21wLWVtaXQt YXNzZXJ0IGxocyByaHMpCisgICAgICAgICAgICAgICAgICAgICAgICAgIChjZHIgaW5zbi1jZWxs KSkpKSkpKSkpCisKKyhkZWZ1biBjb21wLWFzc2VydC1hc3N1bWVzIChfKQorICAiVHVybiAoYXNz dW1lIC4uLikgaW5zbnMgaW50byBhc3NlcnRzLiIKKyAgKG1hcGhhc2ggKGxhbWJkYSAoXyBmKQor ICAgICAgICAgICAgIChsZXQgKChjb21wLWZ1bmMgZikpCisgICAgICAgICAgICAgICAoY29tcC1h c3NlcnQtYXNzdW1lcy1mdW5jKQorICAgICAgICAgICAgICAgKGNvbXAtbG9nLWZ1bmMgY29tcC1m dW5jIDMpKSkKKyAgICAgICAgICAgKGNvbXAtY3R4dC1mdW5jcy1oIGNvbXAtY3R4dCkpKQorDAog Ozs7IEZpbmFsIHBhc3Mgc3BlY2lmaWMgY29kZS4KIAogKGRlZnVuIGNvbXAtYXJncy10by1sYW1i ZGEtbGlzdCAoYXJncykKZGlmZiAtLWdpdCBhL3NyYy9jb21wLmMgYi9zcmMvY29tcC5jCmluZGV4 IGE4YjhlZjk1ZmExNGQuLjJhNWVlYmVlMTA0ZWQgMTAwNjQ0Ci0tLSBhL3NyYy9jb21wLmMKKysr IGIvc3JjL2NvbXAuYwpAQCAtMjAzNyw2ICsyMDM3LDU4IEBAIGVtaXRfbGltcGxlX2luc24gKExp c3BfT2JqZWN0IGluc24pCiAJCQkgICAgICAgbik7CiAgICAgICBlbWl0X2NvbmRfanVtcCAodGVz dCwgdGFyZ2V0MSwgdGFyZ2V0Mik7CiAgICAgfQorICBlbHNlIGlmIChFUSAob3AsIFFhc3NlcnQp KQorICAgIHsKKyAgICAgIExpc3BfT2JqZWN0IGNhbGxlZSA9IFFjb21wX19hc3NlcnQ7CisgICAg ICBlbWl0X2NvbW1lbnQgKFNTREFUQSAoRnByaW4xX3RvX3N0cmluZyAoYXJnWzBdLCBRbmlsKSkp OworICAgICAgaW1tX3JlbG9jX3QgcmVsb2MgPSBvYmpfdG9fcmVsb2MgKGFyZ1swXSk7CisgICAg ICBnY2Nfaml0X3J2YWx1ZSAqYXNzZXJ0X2FyZ3NbaV07CisgICAgICBhc3NlcnRfYXJnc1swXSA9 IGdjY19qaXRfbHZhbHVlX2FzX3J2YWx1ZSAoCisJZ2NjX2ppdF9jb250ZXh0X25ld19hcnJheV9h Y2Nlc3MgKGNvbXAuY3R4dCwKKwkJCQkJICBOVUxMLAorCQkJCQkgIHJlbG9jLmFycmF5LnJfdmFs LAorCQkJCQkgIHJlbG9jLmlkeCkpOworICAgICAgZm9yIChwdHJkaWZmX3QgaiA9IDE7IGogPCBp OyBqKyspCisJYXNzZXJ0X2FyZ3Nbal0gPSBlbWl0X212YXJfcnZhbCAoYXJnW2pdKTsKKworICAg ICAgZ2NjX2ppdF9sdmFsdWUgKnRtcF9hcnIgPQorCWdjY19qaXRfZnVuY3Rpb25fbmV3X2xvY2Fs ICgKKwkJCQkgICAgY29tcC5mdW5jLAorCQkJCSAgICBOVUxMLAorCQkJCSAgICBnY2Nfaml0X2Nv bnRleHRfbmV3X2FycmF5X3R5cGUKKwkJCQkgICAgKGNvbXAuY3R4dCwKKwkJCQkgICAgIE5VTEws CisJCQkJICAgICBjb21wLmxpc3Bfb2JqX3R5cGUsCisJCQkJICAgICBpKSwKKwkJCQkgICAgImxv Y2FsXyVkIik7CisKKyAgICAgIGZvciAocHRyZGlmZl90IGogPSAwOyBqIDwgaTsgaisrKQorCXsK KwkgIGdjY19qaXRfYmxvY2tfYWRkX2Fzc2lnbm1lbnQgKAorCQkJCQljb21wLmJsb2NrLAorCQkJ CQlOVUxMLAorCQkJCQlnY2Nfaml0X2NvbnRleHRfbmV3X2FycmF5X2FjY2VzcyAoCisJCQkJCQkJ CQkgIGNvbXAuY3R4dCwKKwkJCQkJCQkJCSAgTlVMTCwKKwkJCQkJCQkJCSAgZ2NjX2ppdF9sdmFs dWVfYXNfcnZhbHVlICh0bXBfYXJyKSwKKwkJCQkJCQkJCSAgZ2NjX2ppdF9jb250ZXh0X25ld19y dmFsdWVfZnJvbV9pbnQgKGNvbXAuY3R4dCwKKwkJCQkJCQkJCQkJCQkgICAgICAgY29tcC5pbnRf dHlwZSwKKwkJCQkJCQkJCQkJCQkgICAgICAgaikpLAorCQkJCQlhc3NlcnRfYXJnc1tqXSk7CisJ fQorCisgICAgICBnY2Nfaml0X3J2YWx1ZSAqY2FsbCA9IGVtaXRfY2FsbF9yZWYgKGNhbGxlZSwK KwkJICAgICBpLAorCQkgICAgIGdjY19qaXRfY29udGV4dF9uZXdfYXJyYXlfYWNjZXNzIChjb21w LmN0eHQsCisJCQkJCQkgICAgICAgTlVMTCwKKwkJCQkJCSAgICAgICBnY2Nfaml0X2x2YWx1ZV9h c19ydmFsdWUgKHRtcF9hcnIpLAorCQkJCQkJICAgICAgIGNvbXAuemVybyksCisJCSAgICAgZmFs c2UpOworCisgICAgICBnY2Nfaml0X2Jsb2NrX2FkZF9ldmFsIChjb21wLmJsb2NrLAorCQkJICAg ICAgTlVMTCwKKwkJCSAgICAgIGNhbGwpOworICAgIH0KICAgZWxzZSBpZiAoRVEgKG9wLCBRcGhp KSB8fCBFUSAob3AsIFFhc3N1bWUpKQogICAgIHsKICAgICAgIC8qIE5vdGhpbmcgdG8gZG8gZm9y IHBoaXMgb3IgYXNzdW1lcyBpbiB0aGUgYmFja2VuZC4gICovCkBAIC00OTgwLDYgKzUwMzIsMjAg QEAgREVGVU4gKCJjb21wLS1sYXRlLXJlZ2lzdGVyLXN1YnIiLCBGY29tcF9fbGF0ZV9yZWdpc3Rl cl9zdWJyLAogICByZXR1cm4gUW5pbDsKIH0KIAorREVGVU4gKCJjb21wLS1hc3NlcnQiLCBGY29t cF9fYXNzZXJ0LCBTY29tcF9fYXNzZXJ0LCAxLCBNQU5ZLCAwLAorICAgICAgIGRvYzogLyogKi8p CisgIChwdHJkaWZmX3QgbmFyZ3MsIExpc3BfT2JqZWN0ICphcmdzKQoreworICBpZiAoTklMUCAo RmZ1bmNhbGwgKG5hcmdzLCBhcmdzKSkpCisgICAgeworICAgICAgeHNpZ25hbDEgKFFuYXRpdmVf Y29tcGlsZXJfZXJyb3IsCisJCUZjb25zIChidWlsZF9zdHJpbmcgKCJhc3NlcnRpb24gZmFpbGVk IiksCisJCSAgICAgICBGbGlzdCAobmFyZ3MsIGFyZ3MpKSk7CisgICAgfQorCisgIHJldHVybiBR bmlsOworfQorCiBzdGF0aWMgYm9vbAogZmlsZV9pbl9lbG5fc3lzX2RpciAoTGlzcF9PYmplY3Qg ZmlsZW5hbWUpCiB7CkBAIC01MDc2LDYgKzUxNDIsOCBAQCBzeW1zX29mX2NvbXAgKHZvaWQpCiAg IERFRlNZTSAoUWRpcmVjdF9jYWxsLCAiZGlyZWN0LWNhbGwiKTsKICAgREVGU1lNIChRZGlyZWN0 X2NhbGxyZWYsICJkaXJlY3QtY2FsbHJlZiIpOwogICBERUZTWU0gKFFhc3N1bWUsICJhc3N1bWUi KTsKKyAgREVGU1lNIChRYXNzZXJ0LCAiYXNzZXJ0Iik7CisgIERFRlNZTSAoUWNvbXBfX2Fzc2Vy dCwgImNvbXAtLWFzc2VydCIpOwogICBERUZTWU0gKFFzZXRpbW0sICJzZXRpbW0iKTsKICAgREVG U1lNIChRcmV0dXJuLCAicmV0dXJuIik7CiAgIERFRlNZTSAoUXVucmVhY2hhYmxlLCAidW5yZWFj aGFibGUiKTsKQEAgLTUxNzksNiArNTI0Nyw3IEBAIHN5bXNfb2ZfY29tcCAodm9pZCkKICAgZGVm c3ViciAoJlNjb21wX19yZWdpc3Rlcl9sYW1iZGEpOwogICBkZWZzdWJyICgmU2NvbXBfX3JlZ2lz dGVyX3N1YnIpOwogICBkZWZzdWJyICgmU2NvbXBfX2xhdGVfcmVnaXN0ZXJfc3Vicik7CisgIGRl ZnN1YnIgKCZTY29tcF9fYXNzZXJ0KTsKICAgZGVmc3ViciAoJlNuYXRpdmVfZWxpc3BfbG9hZCk7 CiAKICAgc3RhdGljcHJvICgmY29tcC5leHBvcnRlZF9mdW5jc19oKTsKLS0gCjIuMzAuMAoK --00000000000033c40c05bc11ab1f-- From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 24 04:42:47 2021 Received: (at 46670) by debbugs.gnu.org; 24 Feb 2021 09:42:47 +0000 Received: from localhost ([127.0.0.1]:33380 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEqgx-0002Hc-Ff for submit@debbugs.gnu.org; Wed, 24 Feb 2021 04:42:47 -0500 Received: from mx.sdf.org ([205.166.94.24]:60009) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEqgv-0002HS-6j for 46670@debbugs.gnu.org; Wed, 24 Feb 2021 04:42:46 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11O9gduF014254 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 24 Feb 2021 09:42:40 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Wed, 24 Feb 2021 09:42:39 +0000 In-Reply-To: (Pip Cet's message of "Wed, 24 Feb 2021 09:28:39 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Wed, Feb 24, 2021 at 9:04 AM Andrea Corallo wrote: >> Pip Cet writes: >> >> > On Tue, Feb 23, 2021 at 11:36 PM Andrea Corallo wrote: >> >> Pip Cet writes: >> >> > Is this one of them, or am I confused? >> >> >> >> What's suspitions with that? At present I'm admittedly quite done but >> >> it looks okay to me. >> > >> > We're emitting >> > >> > (assume ,lhs (and ,lhs ,rhs)) >> > >> > even when NEGATED is t. >> >> Nope, when NEGATED is t the complete sequence we are emitting is (see >> line just following your diff hunk): >> >> (assume tmp-mvar (not rhs)) > > But tmp-mvar is in the same slot as RHS. > >> (assume lhs (and lhs tmp-mvar)) > > So this is equivalent (after the next SSA rename) to > > (assume lhs (and lhs rhs)) No sorry, after renaming this will be: (assume rhs_2 (not rhs_1)) (assume lhs_2 (and lhs_1 rhs_2)) or if we prefer from an real dump: (assume #(mvar 22593374 2 (not (integer 3 3))) (not #(mvar 22590962 2 (integer 3 3)))) (assume #(mvar 22593448 0 (or marker number)) (and #(mvar 22591258 0 (or marker number)) #(mvar 22593374 2 (not (integer 3 3))))) Sorry my development time budget for this week has been almost entirely consumed now, I'll try to come back on your many mails but I have other duties in line. Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 24 04:47:02 2021 Received: (at 46670) by debbugs.gnu.org; 24 Feb 2021 09:47:02 +0000 Received: from localhost ([127.0.0.1]:33384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEql4-0002OE-43 for submit@debbugs.gnu.org; Wed, 24 Feb 2021 04:47:02 -0500 Received: from mail-oi1-f182.google.com ([209.85.167.182]:44897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEql2-0002Nv-4y for 46670@debbugs.gnu.org; Wed, 24 Feb 2021 04:47:00 -0500 Received: by mail-oi1-f182.google.com with SMTP id x20so1776893oie.11 for <46670@debbugs.gnu.org>; Wed, 24 Feb 2021 01:47:00 -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=OLSknq2IZhmbw9fIfA55zzRCC6t+bm9WSyEt6R+mztM=; b=ulzX4Z554UkkMBwgU3NlNFDjyCL/qvhKka/McL3++Gqv9BhlU3KFH839eAAKOFaktT xvZIbs2U825BKsdm6aUtsVCGjr7RdCsjpfl/ozSvILprruhQBHvP3O+HSKXHZh3UHBye EUAQW0Jr4m1tz2gyyUSZUsxCVO/7ZgrLCUb4eoSdLsTh9rTQdl3o30nTSQr+4drIuABr 0yOhc5F0qDsPqHkyhxqaIPxn1nuuVaSbUhwcez4DuC//BQdxYSSTxL8pMqzG6rE/1PKs 9bhruAPafp3Dj12EMKmMQoZZPtodEMS/OLL6k6bU2GtPRu0YCF0ZF65swKO57OFAI8GA exKA== 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=OLSknq2IZhmbw9fIfA55zzRCC6t+bm9WSyEt6R+mztM=; b=OgKCncX2ochPNJbTPW2YWCHHylRSs9tuX1t8A8yXIZXokhxeRKycWkruvSRF0PLVgN P6TtXL0NjqitV+OHoQxVZ+0k+VEotLcTVut+RpUoaF+jIeWqHuVD/A4ehU/8Q7rMsxxs rS//d/c7mF7UUvtHA6HbDyKLQb1XBcaggs0agIbobbbaCXBwoEdf81uZEPxUq3+pauFG chamcFbpaON5aDfFg84MyhJuYO6cu/LAA4L1NUB4Wsn9PKwtTBw6gzDlkPJinmmxfUh0 e74qc+Xyg0gCRdRHtcpef4xLzvC+d+YN0UVKn9d1An9dJlvrC4Svssxf5keJdkTpar9U OlEA== X-Gm-Message-State: AOAM533pKwt6RJXKVAxKid+IqthARxPyEoR6S9dx0RpylDQxGSLGRPpW 6PmH3inpoGPMwM8o1t/YD5vsuormRDZJ8RJ4Tys= X-Google-Smtp-Source: ABdhPJxUi4B1/SXS6ZX2AVCOWkPaIYUkCzyQ/8DGmRWF+z1014oH7EW5myj8tH51gXpbZBNoK3tsiXTzH8L5UC13R/k= X-Received: by 2002:a05:6808:8e1:: with SMTP id d1mr2200914oic.122.1614160014310; Wed, 24 Feb 2021 01:46:54 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Wed, 24 Feb 2021 09:46:18 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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... From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 24 05:06:33 2021 Received: (at 46670) by debbugs.gnu.org; 24 Feb 2021 10:06:34 +0000 Received: from localhost ([127.0.0.1]:33411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEr3x-0002sD-Mq for submit@debbugs.gnu.org; Wed, 24 Feb 2021 05:06:33 -0500 Received: from mx.sdf.org ([205.166.94.24]:58729) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lEr3v-0002s5-RK for 46670@debbugs.gnu.org; Wed, 24 Feb 2021 05:06:32 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11OA6OU2013444 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Wed, 24 Feb 2021 10:06:24 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Wed, 24 Feb 2021 10:06:24 +0000 In-Reply-To: (Pip Cet's message of "Wed, 24 Feb 2021 09:46:18 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. Indeed I'm happy to answer as I've explained what this means in my previous mail. 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 :/ Andrea From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 07:42:29 2021 Received: (at 46670) by debbugs.gnu.org; 25 Feb 2021 12:42:29 +0000 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 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 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) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Thu, 25 Feb 2021 12:41:42 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 09:58:53 2021 Received: (at 46670) by debbugs.gnu.org; 25 Feb 2021 14:58:53 +0000 Received: from localhost ([127.0.0.1]:38967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFI6P-000455-F2 for submit@debbugs.gnu.org; Thu, 25 Feb 2021 09:58:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50474) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFI6K-00044l-BP for 46670@debbugs.gnu.org; Thu, 25 Feb 2021 09:58:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57009) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFI6E-0008Jp-U0; Thu, 25 Feb 2021 09:58:42 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2257 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lFI6B-0007uj-HR; Thu, 25 Feb 2021 09:58:40 -0500 Date: Thu, 25 Feb 2021 16:58:25 +0200 Message-Id: <83tuq0ry7i.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Thu, 25 Feb 2021 12:41:42 +0000) Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Pip Cet > Date: Thu, 25 Feb 2021 12:41:42 +0000 > Cc: 46670@debbugs.gnu.org, Mauricio Collares > > 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. Please understand and keep in mind that the native-comp branch is still WIP, and as such, it is not yet up to speed with all the documentation and other necessary support info. Andrea's work is still mainly devoted to fixing issues reported against the native-comp code. Polishing the documentation will come later. So please don't expect the documentation to be anywhere near perfect, as we all are used to expect from mainline Emacs code, and please don't blame Andrea for not providing such quality of documentation at this point in time. TIA From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 10:15:42 2021 Received: (at 46670) by debbugs.gnu.org; 25 Feb 2021 15:15:42 +0000 Received: from localhost ([127.0.0.1]:38983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFIMf-0004bG-Vd for submit@debbugs.gnu.org; Thu, 25 Feb 2021 10:15:42 -0500 Received: from mail-oi1-f173.google.com ([209.85.167.173]:45166) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFIMd-0004b0-7A for 46670@debbugs.gnu.org; Thu, 25 Feb 2021 10:15:40 -0500 Received: by mail-oi1-f173.google.com with SMTP id q186so6329711oig.12 for <46670@debbugs.gnu.org>; Thu, 25 Feb 2021 07:15:39 -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=jQiqff+RUgPCybfKc2iqdGPOSPLryzu7AjveWSHik5g=; b=UydT0UXDby8boKseEwYNDmkMiwJNth1Gjp/5UNGBwwUreNBI1t1eluyR0uQCFDHyfi K/qeV034vszgxRk4BAEavZHegcuewI+KTLt0W7UI5sr/JjnQjFuV/udJOsqXe+Fjo4vx z5E10GQHQbZ/6MZF+eGLUriO/Rxi35w3zlimz6gLKVW7xmVPxxfZ1J16qfSDrnEWIEKw W9jGUjgUMGFpvb1FYL737OamZ1DlY+sUtwmoChudq3NkgP/TFZIXrtCUC5vMaHBcYfGr K/Bv4A7sVKa3fmru4nx/gf7k67xBDgBTZG+/apx17DxmToKn9+pvDezcKv10Z9OwSxS7 6Zxg== 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=jQiqff+RUgPCybfKc2iqdGPOSPLryzu7AjveWSHik5g=; b=Dzj4xieEQra5iHqy2fcO+9+WyvvUsPc3EuGsQ3/ejDP0Eyq0JYVKCvtk9nI7fS2zjf 4Qd77poA32mkuWRRqeyMuqjcegOpER985B+KbNR6yGfvJksDVj2egqN9gg1EJa7MWhoy i9HWmm8g+987Jwyxjc/CB9rteXOg4mfJM+7soSEFAdcUi8HGwxEXcA6u6QAuRFB24FwW kXktFDvpdK2+r6d1UGdzo/pEX0hmCC+PY3vbv8QuvHNtPeoM0a+a1RhrtdH5a+EKdFmD F+unJna5hc9Z1lT6+n3gcswUnuku6rAgPVC9Dh1L8ZrkA7AKJQapO5w1NPZeVDEtDvGg sPRw== X-Gm-Message-State: AOAM530lHYl3b+wRj/gbH9pHp34D/Vtn04YHLM7HyIDXTBZYpBuGQzi7 tq3ycrHpanwJ26JJrO5l/g46tYvJnZ6SOMxQEhs= X-Google-Smtp-Source: ABdhPJzArrmv19r7PNym9DLFqv6nwIos7G6nDTXdrX2kvr4awpyzOd5Qlhi5M3Xv5Tj8RJ19pc29B9S0Gm1Oy3zqBpg= X-Received: by 2002:aca:6141:: with SMTP id v62mr2183869oib.30.1614266128844; Thu, 25 Feb 2021 07:15:28 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> <83tuq0ry7i.fsf@gnu.org> In-Reply-To: <83tuq0ry7i.fsf@gnu.org> From: Pip Cet Date: Thu, 25 Feb 2021 15:14:52 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Feb 25, 2021 at 2:58 PM Eli Zaretskii wrote: > Please understand and keep in mind that the native-comp branch is > still WIP, and as such, it is not yet up to speed with all the > documentation and other necessary support info. Thank you for that reminder. You're absolutely correct, of course. Andrea, I'm sorry I haven't made it clear that my standard is "is this something that should be merged", not "is this very good code". It is the latter, as I've said before, and I think the native-comp branch is extremely interesting and should be merged VERY soon. > Andrea's work is > still mainly devoted to fixing issues reported against the native-comp > code. Polishing the documentation will come later. So please don't > expect the documentation to be anywhere near perfect, as we all are > used to expect from mainline Emacs code, and please don't blame Andrea > for not providing such quality of documentation at this point in time. Again, you're absolutely correct. In the specific cases I mentioned, my main concern is that other hackers will find it too frustrating to encounter subtle restrictions that sometimes, incorrectly, feel like pitfalls and look like bugs. Thanks again, Pip From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 10:32:09 2021 Received: (at 46670) by debbugs.gnu.org; 25 Feb 2021 15:32:09 +0000 Received: from localhost ([127.0.0.1]:39022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFIca-00055D-Lo for submit@debbugs.gnu.org; Thu, 25 Feb 2021 10:32:08 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59214) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFIcY-00054J-CN for 46670@debbugs.gnu.org; Thu, 25 Feb 2021 10:32:06 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57595) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFIcS-00072L-Mn; Thu, 25 Feb 2021 10:32:00 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4360 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lFIcS-0006V0-1N; Thu, 25 Feb 2021 10:32:00 -0500 Date: Thu, 25 Feb 2021 17:31:46 +0200 Message-Id: <83czworwnx.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Thu, 25 Feb 2021 15:14:52 +0000) Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> <83tuq0ry7i.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Pip Cet > Date: Thu, 25 Feb 2021 15:14:52 +0000 > Cc: Andrea Corallo , 46670@debbugs.gnu.org, mauricio@collares.org > > > Andrea's work is > > still mainly devoted to fixing issues reported against the native-comp > > code. Polishing the documentation will come later. So please don't > > expect the documentation to be anywhere near perfect, as we all are > > used to expect from mainline Emacs code, and please don't blame Andrea > > for not providing such quality of documentation at this point in time. > > Again, you're absolutely correct. In the specific cases I mentioned, > my main concern is that other hackers will find it too frustrating to > encounter subtle restrictions that sometimes, incorrectly, feel like > pitfalls and look like bugs. Any improvements to the documentation on the branch are of course very welcome, regardless of the fact that it's still WIP. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 11:56:14 2021 Received: (at 46670) by debbugs.gnu.org; 25 Feb 2021 16:56:14 +0000 Received: from localhost ([127.0.0.1]:39098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFJvx-0000lc-VD for submit@debbugs.gnu.org; Thu, 25 Feb 2021 11:56:14 -0500 Received: from mx.sdf.org ([205.166.94.24]:54109) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFJvt-0000lR-MP for 46670@debbugs.gnu.org; Thu, 25 Feb 2021 11:56:12 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11PGu3pj006873 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Thu, 25 Feb 2021 16:56:04 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Thu, 25 Feb 2021 16:56:03 +0000 In-Reply-To: (Pip Cet's message of "Thu, 25 Feb 2021 12:41:42 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > 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 Quoting myself this thread: "The best option is to decide that negative slot numbers are not rendered into libgccjit IR and we consider these virtual to solve these kind of cases." I agree this should be documented. ATM LIMPLE is assumed to be correct but an assertion in the back-end is a good idea. As you know my time is constrained (well I guess this applies to most of us here). Tuesday night I wanted to fix this bug promising my-self to come back on this for documenting what I've discussed here. Indeed I've to round-robin with all the other inputs I've (here and outside the Emacs world) plus all the other things we have pending. > 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? I'd like to state a concept that I think is very pertinent here and most likely overlooked: The difference between propagation related bugs and correctness bugs is very thin if *not* existent at all. Many choices of the compiler depends on what the propagation manage to proves. Misscompilations like exactly this bug (46670) are a perfect example of. I go further, these days this class of bugs is essentially the last we see as misscompilations that gets reported. That said, ATM in comp-tests.el we have ~150 tests of which ~60 verifying the value/type propagation through return type. Indeed I'll be *very* happy to add any kind of test to the testsuite, as I personally tried to do each time I fixed a misscompilation bug reported on the list. On this subject I highly recommend the following, let's adopt what we essentially do for GCC development: - each bug we want to call as such has to come with a reproducer that demostrates it. - each patch has to come with a cover letter explaing why and what is doing. - if the patch is to fix a bug the reproducer is added to the testsuite contextually as a testcase by the patch itself. - patches submitted for inclusion must not cause regressions on the compiler test-suite and must bootstrap cleanly Emacs. If this rules are not followed is just too difficult and, above all, expensive from a time prespective to review. This way of proceeding is just the only sustainable. We probably should document these points somewhere. I myself follow all these rules with the exception of the cover letter as I do not submit patches but just install them, tho I often try to elaborate on the installed fix on this list as I actually did for this specific bug. >> 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? In my previous message I've explained how that assume works and what's his meaning. >> 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". Unfortunatelly I understant that ATM reading the code and comments is not sufficient to understand all mechanism and assumptions involved. This is certainly in part because the compiler is just young and the bring-up entered in final phase just now. That said FWIW my experience with Emacs and other big projects like GCC is that debugging and experimentation is typically needed to get into the deepness of, the expectation that reading code and doc is sufficient is IME at least often just a chimera. Say I write a patch based on some assumption I'm convinced of and this introduces a number of regressions. I'd either pick the simplest non passing testcase and debug it to see what I've been missing or I'd ask if the assumption I used is correct. I'd not claim the compiler is broken in some of its parts to begin with. Indeed as I've said will be my pleasure to answer any question if asked, and even more to welcome any patch that improves the documentation as outcome of this process. > 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. Well it's not meaningless as is used in SSA renaming but again agreed more documentation would be an improvement. > Once we've done that, we can discuss why I think that > would be a very bad design choice. I hope you don't think something you state is likely not to be fully unrestood for now by you is already considered a very bad design choice. > Regards > Pip > Please just reflect on the following: Bringing up this compiler to the point of having a functional Emacs based on it took an enormous quantity time divided in: coding, studying, trial and error, debugging, thinking (not in this other). As I know you are very used to work with compilers and low level programming I'm sure you'll have no problem understanding that the number of commits of this branch does not reflect the time it took to bring it up and verifying it to the point is usable as it is today. This was not to cry but just to say: if something is not as you expect, starting from the assumption that the compiler is working, there are most likely two reasons for that: 1- Some history, thinking, trial and error proved this to be a good solution. 2- Was deemed a non ideal solution but good enough at that moment. Bringing up such a large system implies sometimes to compromise on a single piece of the puzzle waiting for another to come in place. Variable slot naming is one of this cases. If there's something I've learned is that improvements in complex systems are by necessity just incremental, the trick is to find the best path through. Indeed as I said, within time constraints, I'm happy to elaborate on specific cases or design choices if asked. But no solution falling in cases 1 or 2 deserves to be called broken, bad or badly designed. Please lets start from the assumtion that, to begin with, it works. Thanks for your understanding, this will be very appreciated trust me. Andrea From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 25 16:00:28 2021 Received: (at 46670) by debbugs.gnu.org; 25 Feb 2021 21:00:28 +0000 Received: from localhost ([127.0.0.1]:39467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFNkJ-0006fd-KR for submit@debbugs.gnu.org; Thu, 25 Feb 2021 16:00:28 -0500 Received: from mail-ot1-f42.google.com ([209.85.210.42]:44125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFNkG-0006fP-Hc for 46670@debbugs.gnu.org; Thu, 25 Feb 2021 16:00:26 -0500 Received: by mail-ot1-f42.google.com with SMTP id f33so7052312otf.11 for <46670@debbugs.gnu.org>; Thu, 25 Feb 2021 13:00: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=T985JxnqMaBIur/aYjFSdn6qcsVftkPaEtbEiRV6WPI=; b=YOeygGWBmIObEMHrGbMkw4DWO4+E9/fpNfaAzngPN6YiIG39Oe5UCjc8f9/ozqFbkm iv2G56WDArIYFA6NuNVJJKVrTJi3LYSxP7gJcoZzcejMG8gEpgJZvnTLyeiNsgnrdTEw xcr9jLGJyaf/ChzRenCPYzPK1erIJ0EciZUmCiMJFciSrx+0oAy7OhQyHkt6WgLmf+Er ogKNloNoRvIUHmKrbBJO4E87BPUKWYSSXi6AELfR7hQxcaZEWnYi9qmVfqqjRA1FMaZt QXXvTCvD6PSOF4Vtr4ttTUqHrfxtMjWYHCQHH6HCEeVphCtIG9ov0qK7JiRF7rcEPu/F SKQg== 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=T985JxnqMaBIur/aYjFSdn6qcsVftkPaEtbEiRV6WPI=; b=hM4OvH06FGiW0SulH5a+ifMxGkJLQLcdjga6BBnb5VvaC+tDSYDPXHaFFYrHAHHCf/ Usx0l/Eg/xBp8in2SxtPlpxdtDlPwBwobPlDFPHIUB+VyXSEj1eCpNBN2cnoM4l9Sh4M yuk7OlTa4hXNFr0EW2gCyh9GbtiiQx1iH6YtFZ0DTmi8niLRzAuBmQajhKZ5WsTPA2qx vQnaR+7X7mNDPkOwXExt/NyuMnfJJSGCMsJbCdqIjYOAsc1Mr5sIboUaYjpEm/tK4YzD nyLWWtKGQOzYtPI3UotRehoYknfJnkaUg9IHE/5zOsfrIwobJDNhc9NTo+ew2Acvayn9 OuJw== X-Gm-Message-State: AOAM533oDIkoRVPclK1Jas1A3rS0wqC/4f+S/PDbJdCO+pGekbiMG0PF oq2YFmPgfrofKZ8l6EH8Qt+kYWhhUSF2hjRrsNI= X-Google-Smtp-Source: ABdhPJzuPMcAFC9aZHmC3sCAWqBudRv39T6lAfewd11JyiP47PxIQGyM0ZRC/Lnl3KDrSxbAwTwTtMfZKePMOSN5vn8= X-Received: by 2002:a05:6830:3090:: with SMTP id f16mr3860578ots.292.1614286818744; Thu, 25 Feb 2021 13:00:18 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Thu, 25 Feb 2021 20:59:41 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Thu, Feb 25, 2021 at 4:56 PM Andrea Corallo wrote: > Pip Cet writes: > > On Wed, Feb 24, 2021 at 10:06 AM Andrea Corallo wrote: > > 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'd like to repeat that point. I do agree with some of the points you raise. > > 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. Again, that's three conditions that need to happen simultaneously: - no documentation - no code - behavior that contradicts the obvious interpretation In the case of `assume', all three are met: there's no documentation describing it, there's (currently) no code that uses assumes in a non-trivial fashion, and it doesn't mean "assume". > > 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 > > Quoting myself this thread: > > "The best option is to decide that negative slot numbers are not rendered > into libgccjit IR and we consider these virtual to solve these kind of > cases." And then, much later, you were no longer talking about "virtual" negative slot numbers, you were talking about temporary variables (not metavariables) being kept live, and being created for any purpose. Mixed signals, at best. > I agree this should be documented. ATM LIMPLE is assumed to be correct > but an assertion in the back-end is a good idea. (At some point in the future, the backend needs to reject (not eassert, but error) invalid LIMPLE rather than crashing the Emacs process. I understand we're not there yet.) > > 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? > > I'd like to state a concept that I think is very pertinent here and most > likely overlooked: The difference between propagation related bugs and > correctness bugs is very thin if *not* existent at all. Many choices of > the compiler depends on what the propagation manage to proves. I'm not sure what you're saying or how it relates to what I said. > Misscompilations like exactly this bug (46670) are a perfect example of. Of what? This is clearly a correctness bug, not a missed optimization. If fixing it (and actually fixing the underlying issue, which I believe we haven't done yet) involves temporarily disabling some optimizations, then that's what we need to do. We can restore the optimizations later. > That said, ATM in comp-tests.el we have ~150 tests of which ~60 > verifying the value/type propagation through return type. (Yes. That doesn't contradict anything I said.) > On this subject I highly recommend the following, let's adopt what we > essentially do for GCC development: You might want to suggest that on emacs-devel, as it would be a very drastic change. If you, as an individual, want to stop responding to bug reports that don't meet your strict criteria, I don't think there's anyone trying to stop you. Just define a nice keyboard macro saying "I'm sorry, you need to jump through these hoops first". > If this rules are not followed is just too difficult and, above all, > expensive from a time prespective to review. This way of proceeding is > just the only sustainable. I try to avoid speaking in absolutes like that. There's more than one way to do it. > We probably should document these points somewhere. We should probably discuss and agree on them first. > >> 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? > > In my previous message I've explained how that assume works and what's > his meaning. I don't think so. We're looking at (assume mvar1 (not mvar2)) where the two mvars have overlapping lifetimes and share the same slot. That specializes to a contradiction. > >> 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". > > Unfortunatelly I understant that ATM reading the code and comments is > not sufficient to understand all mechanism and assumptions involved. Of course not. I didn't claim otherwise. > This is certainly in part because the compiler is just young It is, which is why assuming it's impeccably correct is not the productive approach right now. > That said FWIW my experience with Emacs and other big projects like GCC > is that debugging and experimentation is typically needed to get into > the deepness of, the expectation that reading code and doc is sufficient > is IME at least often just a chimera. And I didn't say it was sufficient. > Say I write a patch based on some assumption I'm convinced of and this > introduces a number of regressions. I did: the assumption I'm convinced of is that an assume translates into a test at runtime that must be true. > I'd either pick the simplest non > passing testcase and debug it to see what I've been missing I did. The regressions were optimizations that (with an exception, which you fixed) produced correct results from what I'm still convinced are incorrect intermediate representations. > or I'd ask > if the assumption I used is correct. I did. Your response can be summarized as "the tests are passing so there's no bug". > I'd not claim the compiler is > broken in some of its parts to begin with. After considering the alternatives, that still seems overwhelmingly likely to me. > Indeed as I've said will be my pleasure to answer any question if asked, > and even more to welcome any patch that improves the documentation as > outcome of this process. What, if anything, does "(assume mvar1 (not mvar2))" mean? > > Once we've done that, we can discuss why I think that > > would be a very bad design choice. > > I hope you don't think something you state is likely not to be fully > unrestood for now by you is already considered a very bad design choice. Of course I don't. > Please lets start from the assumtion that, to begin with, it works. I find "there is no bug" to be an unhelpful axiom when looking for a bug. Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 14:33:19 2021 Received: (at 46670) by debbugs.gnu.org; 26 Feb 2021 19:33:19 +0000 Received: from localhost ([127.0.0.1]:42562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFirX-0003ot-6W for submit@debbugs.gnu.org; Fri, 26 Feb 2021 14:33:19 -0500 Received: from mx.sdf.org ([205.166.94.24]:50793) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFirV-0003ol-KP for 46670@debbugs.gnu.org; Fri, 26 Feb 2021 14:33:18 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11QJXCwp027916 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 26 Feb 2021 19:33:12 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Fri, 26 Feb 2021 19:33:12 +0000 In-Reply-To: (Pip Cet's message of "Thu, 25 Feb 2021 20:59:41 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: >> On this subject I highly recommend the following, let's adopt what we >> essentially do for GCC development: > > You might want to suggest that on emacs-devel, as it would be a very > drastic change. If you, as an individual, want to stop responding to > bug reports that don't meet your strict criteria, I don't think > there's anyone trying to stop you. Just define a nice keyboard macro > saying "I'm sorry, you need to jump through these hoops first". > >> If this rules are not followed is just too difficult and, above all, >> expensive from a time prespective to review. This way of proceeding is >> just the only sustainable. > > I try to avoid speaking in absolutes like that. There's more than one > way to do it. > >> We probably should document these points somewhere. > > We should probably discuss and agree on them first. Sorry I realized I've been not clear, I was only talking about native compiler misscompilation bugs. There's no need to suggest or discuss that, this is how I work and will as long as I maintain the native compiler. Andrea From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 15:12:12 2021 Received: (at 46670) by debbugs.gnu.org; 26 Feb 2021 20:12:12 +0000 Received: from localhost ([127.0.0.1]:42590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFjTA-0004hU-8Q for submit@debbugs.gnu.org; Fri, 26 Feb 2021 15:12:12 -0500 Received: from eggs.gnu.org ([209.51.188.92]:57462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFjT8-0004hF-3T for 46670@debbugs.gnu.org; Fri, 26 Feb 2021 15:12:10 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41212) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFjT2-0004In-5V; Fri, 26 Feb 2021 15:12:04 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2887 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lFjT1-0005A3-5Q; Fri, 26 Feb 2021 15:12:03 -0500 Date: Fri, 26 Feb 2021 22:11:50 +0200 Message-Id: <83mtvqpp15.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Thu, 25 Feb 2021 20:59:41 +0000) Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Pip Cet > Date: Thu, 25 Feb 2021 20:59:41 +0000 > Cc: 46670@debbugs.gnu.org, Mauricio Collares > > > On this subject I highly recommend the following, let's adopt what we > > essentially do for GCC development: > > You might want to suggest that on emacs-devel, as it would be a very > drastic change. AFAICT, the principles proposed by Andrea are just common sense, and definitely not a drastic change from our existing practices. Granted, not everyone lives up to those goals, but everyone should try. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 15:31:03 2021 Received: (at 46670) by debbugs.gnu.org; 26 Feb 2021 20:31:03 +0000 Received: from localhost ([127.0.0.1]:42631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFjlP-0005Bz-04 for submit@debbugs.gnu.org; Fri, 26 Feb 2021 15:31:03 -0500 Received: from mail-oi1-f180.google.com ([209.85.167.180]:36077) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFjlK-0005BU-Tl for 46670@debbugs.gnu.org; Fri, 26 Feb 2021 15:31:01 -0500 Received: by mail-oi1-f180.google.com with SMTP id j1so11067769oiw.3 for <46670@debbugs.gnu.org>; Fri, 26 Feb 2021 12:30:58 -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=HgQJf3nAeWfAqZZzr66MKBrmClwf/XmSFIXLMGtWVI0=; b=DXcwK50mx79E8l8/P1GV9gJ7LIW1RncdIcjqtfxpHfz9nzsWP4vjNuems2xcSxaq56 MkmTVGunQe6P1r/DzQUWzX8MJqkJZr/HZ3rVFfKxiH/TX4wQjK2dfUjc5k/r/bFYTrta WBwea4lhalWKPyERoy28ILI0I+dexTntrvZb5U7+SyI698eM/DNclNrwSCMjV2WaYsue VxKZ8acbVZ7AAiaZ3pqHpouU/blaokY/dOUmOuHEeT+9bemUfsAmTwTirQ/qUyF9a0Y4 rYvwggOq5NRGE2Tql7tlIk4EztbQvPI/WykEt4RgTWQicITYhnh9CpBCvQdmZ8HuveX0 pL9A== 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=HgQJf3nAeWfAqZZzr66MKBrmClwf/XmSFIXLMGtWVI0=; b=t23EnJnmK91F9xxjvU2a7pYmFBYrAI5hU0J05b0ujizMGjDnoGdnxpMkcHNT65JEDv TwCI0IYAyWyyg9zZOHRjmx+j1RvRXL0Isi0PGp+9WCo/iMHibjt49+26XAC0+FVni2cE 2GSxxSEuXxlNZqs3XUbs/RoIb1P9C+9aHP1DCvxRSJifLJdexBOUVo7/5G00QFU1tKEQ WPXmHH8qZFQe/Sbbi6dtJrzKNTr6R1M49+JPcAulNig/rHWvB0hlzEiFCgd02334d88o NeuJ7iSt1kKSlpW1q9KETWPBQQHAcMbYLiECnYEa5uoTB4oxoNpuKlTwNoQEZqiOCOAH nXeg== X-Gm-Message-State: AOAM531Pmsm2V4WaeqXxtaifyZzbN7LJB8kmlN9iOyGiULzTrkAlROQe BGcVGguepTW156piKn041XfTG48ydXRI4Y+VIVk= X-Google-Smtp-Source: ABdhPJwtaqFqV3qNIPTHUe9fWE+PuxPIh7Xg5Tr5tZb27R/9Cvy+coUghd2fu25FJF7bE3uduM9EF67YJhU3cYlU/xU= X-Received: by 2002:aca:4c5:: with SMTP id 188mr3419311oie.44.1614371453357; Fri, 26 Feb 2021 12:30:53 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> In-Reply-To: From: Pip Cet Date: Fri, 26 Feb 2021 20:30:17 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Andrea Corallo Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 26, 2021 at 7:33 PM Andrea Corallo wrote: > Pip Cet writes: > Sorry I realized I've been not clear, I was only talking about native > compiler misscompilation bugs. Ah, that makes sense. Thanks for the clarification! > There's no need to suggest or discuss > that, this is how I work and will as long as I maintain the native > compiler. Again, not trying to stop you from applying your own criteria. I certainly agree that if it doesn't come with a reproducer, it cannot be a miscompilation bug. Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 15:33:00 2021 Received: (at 46670) by debbugs.gnu.org; 26 Feb 2021 20:33:00 +0000 Received: from localhost ([127.0.0.1]:42640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFjnH-0005FM-Pr for submit@debbugs.gnu.org; Fri, 26 Feb 2021 15:32:59 -0500 Received: from mail-ot1-f47.google.com ([209.85.210.47]:37863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFjnG-0005F7-0D for 46670@debbugs.gnu.org; Fri, 26 Feb 2021 15:32:58 -0500 Received: by mail-ot1-f47.google.com with SMTP id g8so6625845otk.4 for <46670@debbugs.gnu.org>; Fri, 26 Feb 2021 12:32:57 -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=pPN/I3X2+hgHX2UWW/xR+cPztXGC/Av5hrHCj8B9y68=; b=VBRxeAshOWi1VNoFr/8Qznw1eTNYJpV3c4i69mM9pXLFDL3d4qw5UGty4QUeF+s9y4 2ka26dZVHKyiSH37hDcAkJy+cDKzlgF+hQO57rHzru2nN/OyjE+HUr/v+nUnzht9tYNG iK7wfVb1WmyekknhqmZ5NYcXNIoChG7rDOPFZa0bQqUwTFZcOE3aXOKjgCMdMmCXzEZO 8OpJjrW5elUZCqocyxwL2qvp16SWEg2mUFGmnVo2gS8GrY2jTL/p0QhwVTsMh+pSsH1l M7nTmx5L5hAy6R+BLUHEPecke0Htjmcx8GJ3dEDZRsolITjeWFyTiTcWBi1wiA5XCMQc wxZA== 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=pPN/I3X2+hgHX2UWW/xR+cPztXGC/Av5hrHCj8B9y68=; b=fud5KJFbqzI7CtLqymz/UqwhTywORvqcRQs0ZkIFUJXZDif7Gw3VrSWdQvAEV0m1qF V6ltoJSoYPbohw5uAIu/Sj3JC95CV3VQf7FdoT3JBzuk+ki4Cdb4iBDLHkI51PY5iALU SURvNLYrCwgAsFtrk6+LxB2+Q31uOxCKr1IlGARvA+0aGf0L7STlx1HGuz5ca5NQ3JPe +gc4KnU+pQiCKyd7CvuxUYCM/yOTLJ3FrgsqdimFBdeda5TJYc0KV3Knt0sPnalE6nQI sJgVfQ9AyHs72O0y87FSmrgR8wXuEmyZXC8lY5sUh2xbl4KgPufUiExjWiKBHsfG6C10 08Ew== X-Gm-Message-State: AOAM531sKzxi5LmOn2xxk9k3P91fIYRlcChaCocjbqXzVYI0Ipl8hKwR padwaHl8+3bYcBqpHKnwO2FZtJvuYmmf5p5g9Ug= X-Google-Smtp-Source: ABdhPJwEpmUPQc/rsDCS7wKTYFFczYfsi50TEt6AdqQEEeWURlbqgbFccaUU7wQjPHIR8alrPulpLKlXSjE+bTZf3ZA= X-Received: by 2002:a05:6830:3090:: with SMTP id f16mr3788497ots.292.1614371572405; Fri, 26 Feb 2021 12:32:52 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> In-Reply-To: <83mtvqpp15.fsf@gnu.org> From: Pip Cet Date: Fri, 26 Feb 2021 20:32:15 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 26, 2021 at 8:12 PM Eli Zaretskii wrote: > AFAICT, the principles proposed by Andrea are just common sense, and > definitely not a drastic change from our existing practices. I misunderstood Andrea. For miscompilation bugs he's entirely correct, but there are other bugs. > Granted, not everyone lives up to those goals, but everyone should > try. Point taken, I believe. Thanks Pip From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 15:44:25 2021 Received: (at 46670) by debbugs.gnu.org; 26 Feb 2021 20:44:25 +0000 Received: from localhost ([127.0.0.1]:42659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFjyL-0005Wd-EW for submit@debbugs.gnu.org; Fri, 26 Feb 2021 15:44:25 -0500 Received: from mx.sdf.org ([205.166.94.24]:63324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFjyJ-0005WV-JO for 46670@debbugs.gnu.org; Fri, 26 Feb 2021 15:44:24 -0500 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 11QKiJlv026434 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 26 Feb 2021 20:44:19 GMT From: Andrea Corallo To: Pip Cet Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> Date: Fri, 26 Feb 2021 20:44:19 +0000 In-Reply-To: (Pip Cet's message of "Fri, 26 Feb 2021 20:30:17 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, Mauricio Collares X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > On Fri, Feb 26, 2021 at 7:33 PM Andrea Corallo wrote: >> Pip Cet writes: >> Sorry I realized I've been not clear, I was only talking about native >> compiler misscompilation bugs. > > Ah, that makes sense. Thanks for the clarification! > >> There's no need to suggest or discuss >> that, this is how I work and will as long as I maintain the native >> compiler. > > Again, not trying to stop you from applying your own criteria. I > certainly agree that if it doesn't come with a reproducer, it cannot > be a miscompilation bug. A compiler does essentially one thing, compiling. IOW here I'm referring to everything that is not infrastructure integration. Andrea From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 00:07:42 2021 Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 05:07:42 +0000 Received: from localhost ([127.0.0.1]:43040 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFrp9-0000dx-OG for submit@debbugs.gnu.org; Sat, 27 Feb 2021 00:07:42 -0500 Received: from mail-oi1-f174.google.com ([209.85.167.174]:37743) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFrp7-0000dk-WE for 46670@debbugs.gnu.org; Sat, 27 Feb 2021 00:07:26 -0500 Received: by mail-oi1-f174.google.com with SMTP id l133so12091860oib.4 for <46670@debbugs.gnu.org>; Fri, 26 Feb 2021 21:07:26 -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=p5C7XJ6mrx73/sP9d/TDbvyz15sQH+1Xe03Fbv1rG0o=; b=L3Ijvb5PblZinip3KqHrv42r88rvw/FW+qg+O0i4vqMB7GnEdRHEAa/6KLFg8+u++a c0/eXLcxnwiwjbaeUuf1dsOsGKR+tAR31e9P7z60dCwvUS0gJkKVjSdRyLLfsyrQeMOb kSca3zlPK2xTELWvexpHUsX5qfw6OaTvFiNJnx7BVw7HS+JEMA+NE0IuzCI8nmqB7F87 Xdt3AHZHmUqI7W17FaWNHDoepSeG6ZbKWAoZVhqtr1XjsBniUljR39hwvdDtfgFhmdwl kQO192vT4akibtptaPMV74zzjhED+C0qvqc8KMR8M8tW+voQiIqkwH9RdPttnJlmSP3C 1oBA== 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=p5C7XJ6mrx73/sP9d/TDbvyz15sQH+1Xe03Fbv1rG0o=; b=NIAYqML/NZODPqUYs6U7GFwyx5TDya8uC954NAd79U9AsE++fmLVKIcrdUkbQ5Mvru B22nNL015FE1+yU+b1XsbsWuRgZR+FS/a46OLzYgr7czpW7T/05Wxp4qDZnjHraMkh88 dACcmrFDbeDcsTdTdRNxFAzGQILeWg4xh3fkT+iFuWEC6HV94arN7pFw9ydGDNOCn7Ir 5uEfkk9NOoSiaL/H2qDsaO9yf4mwhjDQydOpdyRkR3dpygnl9I4G/AJI8kGix5PtoXIR jwLRvVyVLYCuypb5iN8ieQzAyTm6af3UMZW3UkZ1AFhMS4vfVgj+DdG1OWEhj62znDJ8 kZVQ== X-Gm-Message-State: AOAM532Y+BlbX8H/U/3TgwRJNQAi2pyZVze5ujVhu29WuhYWT87+CtnB zQC1U/q5Glafihg2TyCy2ENi0l2Pgo4Sbx+E/+0= X-Google-Smtp-Source: ABdhPJw4a+KvmD6UxV066KoN4HavhUZtCdk58FVDuqU9oymp93A4F54V8QVDXdVKo7vXERGoMkKAFhevJZVTTqfifUA= X-Received: by 2002:aca:6141:: with SMTP id v62mr4420507oib.30.1614402440425; Fri, 26 Feb 2021 21:07:20 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> In-Reply-To: <83mtvqpp15.fsf@gnu.org> From: Pip Cet Date: Sat, 27 Feb 2021 05:06:43 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Feb 26, 2021 at 8:12 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Thu, 25 Feb 2021 20:59:41 +0000 > > Cc: 46670@debbugs.gnu.org, Mauricio Collares > > > > > On this subject I highly recommend the following, let's adopt what we > > > essentially do for GCC development: > > > > You might want to suggest that on emacs-devel, as it would be a very > > drastic change. > > 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: 1. We're emitting strange "assume" insns. 2. These are pseudo-insns which are not rendered into functional code. 3. We do not have a facility for converting these "assume" insns into functional code which asserts they hold at runtime. 4. We have test cases which ensure the "assume" insns are actually generated as they currently are. How, assuming for the moment that the "strange" in (1) actually means "buggy", are we supposed to fix this? A patch changing (1) will be rejected as invalid because there is no reproducer. It will also be rejected as broken because the test cases will fail. A patch changing (2) (e.g. a new compiler feature which makes use of the assumes) will be rejected as broken because it will generate incorrect code. A patch changing (3) will be rejected because the new assertions will initially fail, because of (1). A patch changing (4) will be rejected because it would mean dropping tests which appear to work. A patch changing (1), (3), and (4) at the same time will be rejected because it wouldn't be incremental. I think, but am willing to be convinced I'm wrong, that this is the situation we're in. I can prepare patches changing any combination of (1), (2), (3), and (4). Pip From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 02:49:37 2021 Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 07:49:38 +0000 Received: from localhost ([127.0.0.1]:43131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFuM5-0006iH-Lp for submit@debbugs.gnu.org; Sat, 27 Feb 2021 02:49:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40264) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFuM3-0006i3-R5 for 46670@debbugs.gnu.org; Sat, 27 Feb 2021 02:49:36 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56708) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFuLy-00060h-3x; Sat, 27 Feb 2021 02:49:30 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1767 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lFuLw-0003Uv-Lj; Sat, 27 Feb 2021 02:49:29 -0500 Date: Sat, 27 Feb 2021 09:49:20 +0200 Message-Id: <835z2eosqn.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sat, 27 Feb 2021 05:06:43 +0000) Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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: > > 1. We're emitting strange "assume" insns. > 2. These are pseudo-insns which are not rendered into functional code. > 3. We do not have a facility for converting these "assume" insns into > functional code which asserts they hold at runtime. > 4. We have test cases which ensure the "assume" insns are actually > generated as they currently are. > > 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. Maybe I don't understand the issue well enough? From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 04:40:37 2021 Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 09:40:37 +0000 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 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 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) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> In-Reply-To: <835z2eosqn.fsf@gnu.org> From: Pip Cet Date: Sat, 27 Feb 2021 09:39:50 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 05:24:32 2021 Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 10:24:32 +0000 Received: from localhost ([127.0.0.1]:43183 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFwlz-0001vS-L9 for submit@debbugs.gnu.org; Sat, 27 Feb 2021 05:24:31 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lFwly-0001vE-71 for 46670@debbugs.gnu.org; Sat, 27 Feb 2021 05:24:30 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57884) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lFwlq-0000Iu-Os; Sat, 27 Feb 2021 05:24:22 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3611 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lFwlq-0007v6-4k; Sat, 27 Feb 2021 05:24:22 -0500 Date: Sat, 27 Feb 2021 12:24:11 +0200 Message-Id: <83v9adolkk.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sat, 27 Feb 2021 09:39:50 +0000) Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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. My point is that if those "assume" forms never generate any real code in the produced .eln file, then why worry about them? They are like comments: if you don't like comments, just ignore them; they don't actually affect any executable code. > 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. But anyone who presents patches must understand that people who review those patches could decide the issue the patches try to fix is not worth fixing, or isn't a problem in the first place. If you want to avoid such decisions, _then_ you need to satisfy those rules. IOW, they aren't rules for submitting stuff, they are rules for considering the submitted stuff as significant and for attracting the attention of the individuals responsible for the respective code. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 07:40:36 2021 Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 12:40:37 +0000 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 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 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) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.fsf@gnu.org> In-Reply-To: <83v9adolkk.fsf@gnu.org> From: Pip Cet Date: Sat, 27 Feb 2021 12:39:48 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 08:30:27 2021 Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 13:30:27 +0000 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 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 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 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 Date: Sat, 27 Feb 2021 15:30:01 +0200 Message-Id: <83o8g5ocyu.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sat, 27 Feb 2021 12:39:48 +0000) Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 12:16:06 2021 Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 17:16:06 +0000 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 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 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) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.fsf@gnu.org> <83o8g5ocyu.fsf@gnu.org> In-Reply-To: <83o8g5ocyu.fsf@gnu.org> From: Pip Cet Date: Sat, 27 Feb 2021 17:15:20 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 27 13:41:11 2021 Received: (at 46670) by debbugs.gnu.org; 27 Feb 2021 18:41:11 +0000 Received: from localhost ([127.0.0.1]:45378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lG4Wc-000495-V2 for submit@debbugs.gnu.org; Sat, 27 Feb 2021 13:41:11 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lG4Wa-00048r-IO for 46670@debbugs.gnu.org; Sat, 27 Feb 2021 13:41:09 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37113) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lG4WU-00036R-6N; Sat, 27 Feb 2021 13:41:02 -0500 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2354 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lG4WT-0004Iw-5P; Sat, 27 Feb 2021 13:41:01 -0500 Date: Sat, 27 Feb 2021 20:40:50 +0200 Message-Id: <834khxnykt.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: (message from Pip Cet on Sat, 27 Feb 2021 17:15:20 +0000) Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.fsf@gnu.org> <83o8g5ocyu.fsf@gnu.org> X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > From: Pip Cet > Date: Sat, 27 Feb 2021 17:15:20 +0000 > Cc: Andrea Corallo , 46670@debbugs.gnu.org, mauricio@collares.org > > > 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 have my own ways of judging what people say and deciding when they are sound and when they aren't. If you want to question my judgment as well, you are talking to the wrong guy. > > 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. You are welcome to step up to be the Emacs maintainer, and then act according to your opinions. > > 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. When there's evidence, there's no doubt, and such issues should be and are taken care of. Where there's no evidence, we trust the judgment of the best experts we have, when they show (as they usually do) they carefully considered the issue before expressing their opinions. The rest of us, if we don't agree with the expert judgment, get to work harder to find the evidence. There's no way around this. > > > 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. I suggest that you consider deeds before you consider words. I challenge you to find any response from Andrea where he dismissed any report without first considering it seriously and responding to the report with his reasoning. > 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. See above. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 28 03:15:08 2021 Received: (at 46670) by debbugs.gnu.org; 28 Feb 2021 08:15:08 +0000 Received: from localhost ([127.0.0.1]:45795 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGHEK-0000Of-8h for submit@debbugs.gnu.org; Sun, 28 Feb 2021 03:15:08 -0500 Received: from mail-oi1-f180.google.com ([209.85.167.180]:35346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGHEJ-0000No-3J for 46670@debbugs.gnu.org; Sun, 28 Feb 2021 03:15:07 -0500 Received: by mail-oi1-f180.google.com with SMTP id i21so12512123oii.2 for <46670@debbugs.gnu.org>; Sun, 28 Feb 2021 00:15:07 -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=KM/gk9FXrBhdSHOE5k6Uc3WhexVnaQ8/u/1RRai5F64=; b=j6nBjO+BGcklIBBEJwmyfujpzSAr+5fUsq17uHHoR8JJUu6LGD7QNunC5Pdb7/RNjU fPAwpxZgbKqvpK0ZwVI6EkDsLCpRTTpZLugeRVOz6Ty7ioXPRaWoft4Q2EE+SUFbW7Ii huTEhNttGbySvGXLKSnVdEtJwwHMZyxs1DZ5T3EjwEcq701bZ5304cv7O8L3LCMyB2tR TuBr+vYgzHeU5e/4gINj/EhnWroF3IcSt4ptgvpRwh1moOOtR1x3Rj1E+LnIwXjv13ND pd+DLv+F8LUfEKG5zMiwTQXDFWvgk4IiOa8DWGru0MHqvvW/Nc6EUPXS0UeAthTIDJpk 1iYg== 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=KM/gk9FXrBhdSHOE5k6Uc3WhexVnaQ8/u/1RRai5F64=; b=hAR7cfmnSYV1cJLODXhDmU/fv6PsLwvgAtWfvOtrH8LB0LwAA6uNystR1z1iQD/Lre NGPOZUeC1zEeBeRkEpIBJWa/j55uQ0Bo4O8nd5JWW7mVaxQ0L7wdIhrsZY0eR6DH5ssP Z7JsAeSFQ3wLftq85YHvozFcSzUTF+Bu9N+lRh+aE7EXK+L+1qb34FBRg8++Zw8/+2yR tbHMNVp+LKDOttLPGhkYT4M2L69hPifi9+dXnlFCR0vKC0paHhjVrO50cPJ7CB6vROuy VvHQQ2opx04osE7tIqLaNbHwTi90URBqCriojzngMJP2sj2/WqwwEy+X7huewT6HShbe Tprw== X-Gm-Message-State: AOAM532Dpjh5iHGqj7AegYNmTRWAgWeeUia4N/c+6HCpiiB7T7wTz8Sd jhcthYOhi6ygiZzj0vESuDCt05+N97+yPW7cFCw= X-Google-Smtp-Source: ABdhPJx1XUel5Fv82Uz9CyAsfXTSIQe18q0ZhYGqSjziSuZNJPKeP0pt03zM9DWLCsjB8u/l3rydc8/GyHGxxiASK+Q= X-Received: by 2002:aca:4c5:: with SMTP id 188mr7748351oie.44.1614500101345; Sun, 28 Feb 2021 00:15:01 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.fsf@gnu.org> <83o8g5ocyu.fsf@gnu.org> <834khxnykt.fsf@gnu.org> In-Reply-To: <834khxnykt.fsf@gnu.org> From: Pip Cet Date: Sun, 28 Feb 2021 08:14:24 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: 46670@debbugs.gnu.org, mauricio@collares.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Feb 27, 2021 at 6:41 PM Eli Zaretskii wrote: > > I take it you've read through the code, understood it all, and > > concluded the reasons were "sound", then? > > I have my own ways of judging what people say and deciding when they > are sound and when they aren't. If you want to question my judgment > as well, you are talking to the wrong guy. You're using "sound" to mean "superficially correct". I understood it to have its mathematical (and legal) meaning, "irrefutably correct". > > I have my own opinions about why Emacs attracts so few volunteers and > > drives away so many of those who might be. > > You are welcome to step up to be the Emacs maintainer, and then act > according to your opinions. There's a whole spectrum between "we shouldn't fly into that mountain" and "let me take the controls". > > > 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. > > When there's evidence, there's no doubt, and such issues should be and > are taken care of. Where there's no evidence, we trust the judgment > of the best experts we have, when they show (as they usually do) they > carefully considered the issue before expressing their opinions. The > rest of us, if we don't agree with the expert judgment, get to work > harder to find the evidence. There's no way around this. Let's see how this plays out. From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 01 00:24:21 2021 Received: (at 46670) by debbugs.gnu.org; 1 Mar 2021 05:24:21 +0000 Received: from localhost ([127.0.0.1]:47807 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGb2b-00061t-EX for submit@debbugs.gnu.org; Mon, 01 Mar 2021 00:24:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGb2Z-00061h-6x for 46670@debbugs.gnu.org; Mon, 01 Mar 2021 00:24:19 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38774) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lGb2T-00075c-Iy; Mon, 01 Mar 2021 00:24:13 -0500 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1lGb2J-0003PK-TW; Mon, 01 Mar 2021 00:24:04 -0500 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Pip Cet In-Reply-To: (message from Pip Cet on Sun, 28 Feb 2021 08:14:24 +0000) Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.fsf@gnu.org> <83o8g5ocyu.fsf@gnu.org> <834khxnykt.fsf@gnu.org> Message-Id: Date: Mon, 01 Mar 2021 00:24:03 -0500 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 46670 Cc: eliz@gnu.org, mauricio@collares.org, 46670@debbugs.gnu.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > You're using "sound" to mean "superficially correct". I understood it > to have its mathematical (and legal) meaning, "irrefutably correct". I was not following this thread, but here > > > I take it you've read through the code, understood it all, and > > > concluded the reasons were "sound", then? you seem to be talking about judging the reasons to make a change. Generally, that is not a question of mathematics alone. Sometimes a bug is simple and a fix is cleary correct. But usually what to change and how is a matter of judgment, and the best answer is not irrefutably right. -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Mon Mar 01 01:41:30 2021 Received: (at 46670) by debbugs.gnu.org; 1 Mar 2021 06:41:31 +0000 Received: from localhost ([127.0.0.1]:47886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGcFG-00080z-Mt for submit@debbugs.gnu.org; Mon, 01 Mar 2021 01:41:30 -0500 Received: from mail-oi1-f178.google.com ([209.85.167.178]:35987) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lGcFE-00080m-Hu for 46670@debbugs.gnu.org; Mon, 01 Mar 2021 01:41:29 -0500 Received: by mail-oi1-f178.google.com with SMTP id j1so17039278oiw.3 for <46670@debbugs.gnu.org>; Sun, 28 Feb 2021 22:41:28 -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=035S3wktit4I1mqpJ/eQyzgFcuai15tLy/WC67xMKbo=; b=paDC5KgfMhnRqswtdjZy2GIivuZCfbau8sr9uoCKPRBaplFtwyysVNFsIXIGlbeJDm 7Y14f7q+4bHHhQTtBJLH2ic8wDvjtHB7fdLNMsKinuEJ3IC1/W97oh4smUVpeqWmKjIs ijV5M0O3f7ndAOiSmT4jtm2hPKFgM4iScdDznFfvUgZ7PPiZzmfKVrP6B4wUA+hOzRa9 3Ed9b2URYB5KeWE/grp6XhBw8+KSr5H7D5Yxu9SFGCuhWH2xUCua3njO9ZjxKMjTRQ+3 77fUW0M9iaDLc/OH4yLU1P/Wv73Yh1QCvEFCMqt5S+T0BrQfPVGLtcIAvZAWSVGZ4Y6H PsRw== 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=035S3wktit4I1mqpJ/eQyzgFcuai15tLy/WC67xMKbo=; b=Ng/GjWbvmd51SVYDkO/fcPGMWuzIiPTU6rN0EEF4qI3ahEmMtKhDtvqu5fBkR7GKer 3cIKFjdwFkxq9zl86GfyQHGvU67UVM0RbwNk524uet96w9ieb7UKrFM8qJnnM7kGMp50 u0PDBxJupjf+sXcMrfigkybMYMIONCah1amoVSiSs3X+Jh58/zNxMGHxQbR5DWbIja26 h9bi0micZSZNQVmus+FFIUy0x1pwchSIOiGDwWGYgs2NFgDJ9hwRXMicHrByDbyhitlq witdoCzZMujpebmlvrqM01eucbUNG3DIuBSpX8Quwk9dzay8jV4UqPkAyg+dWRyQURcd 20cA== X-Gm-Message-State: AOAM530vH9crsSRcR6uFrqdSKXVlc75VKsAIUMQvz70B/irzlANexkzy rWS2GqfKFhLmzrnp4unqPbnM3i7KuLe+qj1Scfc= X-Google-Smtp-Source: ABdhPJxLinQzMPdP6aJ5shpy5GguR0pPNmkYwMlBilemXcAogGV1p2MkVtt7prU4ig7dv/3T5k2sbPH4UXFisN8jzL8= X-Received: by 2002:aca:4c5:: with SMTP id 188mr10617178oie.44.1614580882739; Sun, 28 Feb 2021 22:41:22 -0800 (PST) MIME-Version: 1.0 References: <87a6ry46uc.fsf@collares.org> <83mtvqpp15.fsf@gnu.org> <835z2eosqn.fsf@gnu.org> <83v9adolkk.fsf@gnu.org> <83o8g5ocyu.fsf@gnu.org> <834khxnykt.fsf@gnu.org> In-Reply-To: From: Pip Cet Date: Mon, 1 Mar 2021 06:40:46 +0000 Message-ID: Subject: Re: bug#46670: 28.0.50; [feature/native-comp] possible miscompilation affecting lsp-mode To: rms@gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 46670 Cc: eliz@gnu.org, mauricio@collares.org, 46670@debbugs.gnu.org, Andrea Corallo X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Mar 1, 2021 at 5:24 AM Richard Stallman wrote: > > You're using "sound" to mean "superficially correct". I understood it > > to have its mathematical (and legal) meaning, "irrefutably correct". > > I was not following this thread, but here > > > > > I take it you've read through the code, understood it all, and > > > > concluded the reasons were "sound", then? > > you seem to be talking about judging the reasons to make a change. We're not, no. We're talking about the reasons given to justify the claim that a pseudo-insn emitted by the compiler is not "suspicious". To say those reasons are "sound" is to say that my initial objection to the pseudo-insn was answered by the explanation proffered and is now obviously invalid. I think it's a matter of further discussion, not that it is, at this point, obviously valid. (As it turns out, my objection was valid, at least in part. A small number of the problematic assumptions are now, apparently, no longer being emitted.) Pip From unknown Fri Sep 12 16:03:27 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Mon, 29 Mar 2021 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator