From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#74771: Native compilation bug with struct predicates when lexical binding enabled (HEAD) Date: Wed, 08 Jan 2025 11:51:07 +0000 Message-ID: <871pxdfrrr.fsf@protonmail.com> References: <0446a656-1fa2-4160-a8ba-69c060a52589@risk-engineering.org> <865xn4ul9t.fsf@gnu.org> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1968"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , eric.marsden@risk-engineering.org, 74771@debbugs.gnu.org To: Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 08 12:52:30 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tVUbt-0000Ix-JV for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 08 Jan 2025 12:52:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVUbX-0006F1-2S; Wed, 08 Jan 2025 06:52:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tVUbU-0006Ek-0F for bug-gnu-emacs@gnu.org; Wed, 08 Jan 2025 06:52:04 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tVUbT-0001KG-Nk for bug-gnu-emacs@gnu.org; Wed, 08 Jan 2025 06:52:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:References:In-Reply-To:From:Date:To:Subject; bh=O7aUALWHAK/Zc6/ii8aO3WSl5OfYodSyBkyteYaPAbc=; b=f2N/maA8BSJ68Tj9+x2Qjw2vqe4HWcMGPvLp9pygFXGTUkvtmb2rrClBQbf5dHDy4nPPbP+Y/S1pi2SwtLVgkpZFafxAwcXqT005uwy33Y3+ZOCKSdO6KXR4MkIKmEhssU+/9fXb5tOBeaSwMoYdT/tq2l1DUV9b7jn/ej5vqZ1GcYTFqbKc5uEghqOxdN6agxO5iYsLkF0Lw/AJBnE/kMEPFSy4fg6jytDlX0SfJ1vEkuiyTt3g+a2vzOWTbMfXVug+gWAStRrrFPdgabUYB00E5JEHuF45AtpXFA2zzyb/IohnZnMNHhZINVCkEW6Zmxma3IODUzjyYiaKC9GuyQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tVUbS-0006qf-I1 for bug-gnu-emacs@gnu.org; Wed, 08 Jan 2025 06:52:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 08 Jan 2025 11:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74771 X-GNU-PR-Package: emacs Original-Received: via spool by 74771-submit@debbugs.gnu.org id=B74771.173633708026218 (code B ref 74771); Wed, 08 Jan 2025 11:52:02 +0000 Original-Received: (at 74771) by debbugs.gnu.org; 8 Jan 2025 11:51:20 +0000 Original-Received: from localhost ([127.0.0.1]:46208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVUal-0006on-WD for submit@debbugs.gnu.org; Wed, 08 Jan 2025 06:51:20 -0500 Original-Received: from mail-10628.protonmail.ch ([79.135.106.28]:52871) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tVUaj-0006oK-51 for 74771@debbugs.gnu.org; Wed, 08 Jan 2025 06:51:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736337070; x=1736596270; bh=O7aUALWHAK/Zc6/ii8aO3WSl5OfYodSyBkyteYaPAbc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=qtzOGvam6qjRvtyUjhHYtADbaOTjYj6LdU32xPcpbPrhUEuQDhmk7UaVlmrN7ThyC s7ie4yNw9nyleqkTD6z3SVExz/UWSPz5+uqUBUscLRsHhn3QG8jlnewCKSvKG/kBDI qEMLO5jwdSmB22+ZJVnah53fzks0VR3e1Mw2xDCv2R+sFU6cSmhVAJnM6V6Qj/uHX4 SlzUIa+2LLDrEjJqeeCEE4qNIAKzwsCRqZxoUdkxQbSkYc3mRmhJGN0vOFPv8a+fK6 WZHkisIeRONRgJnRtdumtSvLSXgblIVW+AER9oqCrK4/csTxMi6UGryh7Gz1N5XtYG mCY64tPMT9MBg== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c65040cd37f5acea461b30c554b179eafdba2031 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298769 Archived-At: "Andrea Corallo" writes: > Eli Zaretskii writes: > >>> Cc: 74771@debbugs.gnu.org >>> From: Andrea Corallo >>> Date: Wed, 11 Dec 2024 17:29:34 -0500 >>> >>> Eric Marsden writes: >>> >>> > Hi, >>> > >>> > With the attached source file, Emacs miscompiles the struct predicate= such >>> > that a repeated call to the predicate on a non-struct object returns = t. >>> > This occurs with current HEAD on Linux/AMD64, but not on the Emacs 30= .0.92 >>> > pretest. It does not occur when the lexical binding cookie is not pre= sent. >>> > >>> > % /opt/emacs/bin/emacs -Q --batch --eval "(load (native-compile \"/tm= p/bug.el\"))" -f run >>> > Loading /home/emarsden/.emacs.d/eln-cache/31.0.50-c021c983/bug-59c4b2= 7c-c70072f9.eln (native compiled elisp)... >>> > Running in GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Vers= ion 3.24.43, cairo version 1.18.2) >>> > =C2=A0of 2024-12-09 >>> > is? nil >>> > is? t=C2=A0=C2=A0 ;; expecting nil >>> > bar: 111 >>> > >>> > ;;; -*- lexical-binding: t -*- >>> > ;; >>> > ;; /opt/emacs/bin/emacs -Q --batch -L . --eval "(load (native-compile= \"/tmp/bug.el\"))" -f run >>> > >>> > (require 'cl-lib) >>> > >>> > (cl-defstruct foobles bar baz) >>> > >>> > (defun bug (foo) >>> > (message "is? %s" (foobles-p foo)) >>> > (message "is? %s" (foobles-p foo)) >>> > (message "bar: %s" (foobles-bar foo))) >>> > >>> > (defun run () >>> > (message "Running in %s" (version)) >>> > (let ((foo "foo")) >>> > (bug foo))) >>> >>> Hi Eric, >>> >>> thanks for the report, I'll look at this in the coming days. >> >> Any progress here? > > Not so far, I'm on holiday this days so I don't have much time for > coding, it's in my todo list tho. No activity in a while, so I tried reproducing this: bug's still there. Can you repeat for me what (assume #s(comp-mvar (t) nil nil nil nil nil) (not #s(comp-mvar (foobles) n= il nil nil nil nil))) is supposed to mean? To me, it appears to mean "the value of the first mvar is different from the value of the second mvar, which is of type foobles". This doesn't say anything about the type of the first mvar, assuming there is more than one value of the foobles type; if this is the correct interpretation, we need to stop copying the typeset in this case: diff --git a/lisp/emacs-lisp/comp-cstr.el b/lisp/emacs-lisp/comp-cstr.el index 3d46cc8c6ae..5d87ff75703 100644 --- a/lisp/emacs-lisp/comp-cstr.el +++ b/lisp/emacs-lisp/comp-cstr.el @@ -1176,14 +1176,11 @@ comp-cstr-value-negation "Negate values in SRC setting the result in DST. DST is returned." (with-comp-cstr-accessors - (if (or (valset src) (range src)) - (setf (typeset dst) () - (valset dst) (valset src) - (range dst) (range src) - (neg dst) (not (neg src))) - (setf (typeset dst) (typeset src) - (valset dst) () - (range dst) ())) + (and (or (valset src) (range src)) + (setf (typeset dst) () + (valset dst) (valset src) + (range dst) (range src) + (neg dst) (not (neg src)))) dst)) =20 (defun comp-cstr-negation-make (src) I see two other possibilities: 1. it means the lhs mvar is of type "foobles", but not identical to the second mvar. This is what comp-cstr-negation-make currently assumes. In this case, comp--add-cond-cstrs should not be emitting this pseudo-insn for the case in which the lhs mvar is known not to be of type "foobles", but nothing else is known about its value: diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el index 269eae315e4..d5c512fbdc3 100644 --- a/lisp/emacs-lisp/comp.el +++ b/lisp/emacs-lisp/comp.el @@ -2033,11 +2033,7 @@ comp--add-cond-cstrs (comp--emit-assume 'and mvar-tested (make--comp-mvar :type (comp-cstr-cl-tag mvar-tag= )) (comp--add-cond-cstrs-target-block b bb2) - nil) - (comp--emit-assume 'and mvar-tested - (make--comp-mvar :type (comp-cstr-cl-tag mvar-tag= )) - (comp--add-cond-cstrs-target-block b bb1) - t)) + nil)) (`((set ,(and (pred comp-mvar-p) cmp-res) (,(pred comp--call-op-p) ,(and (or (pred comp--equality-fun-p) 2. it means the lhs mvar is not of type "foobles". In this case, comp-cstr-value-negation should make the lhs mvar have a negated cstr with type "foobles": diff --git a/lisp/emacs-lisp/comp-cstr.el b/lisp/emacs-lisp/comp-cstr.el index 3d46cc8c6ae..03a00123f64 100644 --- a/lisp/emacs-lisp/comp-cstr.el +++ b/lisp/emacs-lisp/comp-cstr.el @@ -1183,7 +1183,8 @@ comp-cstr-value-negation (neg dst) (not (neg src))) (setf (typeset dst) (typeset src) (valset dst) () - (range dst) ())) + (range dst) () + (neg dst) (not (neg src)))) dst)) =20 (defun comp-cstr-negation-make (src) Note that if (2) is intended, that is a really strange interpretation of what "not" means: it's negating a cstr (a set of values), not an mvar (a specific value), so why is the argument an mvar? We could make this change, and then try to recover whichever optimizations that disables: diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el index 269eae315e4..bcc0628235a 100644 --- a/lisp/emacs-lisp/comp.el +++ b/lisp/emacs-lisp/comp.el @@ -2035,7 +2035,7 @@ comp--add-cond-cstrs (comp--add-cond-cstrs-target-block b bb2) nil) (comp--emit-assume 'and mvar-tested - (make--comp-mvar :type (comp-cstr-cl-tag mvar-tag= )) + (comp--type-to-cstr (comp-cstr-cl-tag mvar-tag)) (comp--add-cond-cstrs-target-block b bb1) t)) (`((set ,(and (pred comp-mvar-p) cmp-res) In any case, please consider documenting the pseudo-insns. not-eq-to-mvar and not-matching-cstr are two very different things! Pip