From unknown Wed Jun 18 23:18:39 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#78606 <78606@debbugs.gnu.org> To: bug#78606 <78606@debbugs.gnu.org> Subject: Status: 31.0.50; [nativecomp] native-ice in emit_mvar_rval Reply-To: bug#78606 <78606@debbugs.gnu.org> Date: Thu, 19 Jun 2025 06:18:39 +0000 retitle 78606 31.0.50; [nativecomp] native-ice in emit_mvar_rval reassign 78606 emacs submitter 78606 Pip Cet severity 78606 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue May 27 09:38:34 2025 Received: (at submit) by debbugs.gnu.org; 27 May 2025 13:38:34 +0000 Received: from localhost ([127.0.0.1]:40291 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uJuVl-00087T-Ni for submit@debbugs.gnu.org; Tue, 27 May 2025 09:38:34 -0400 Received: from lists.gnu.org ([2001:470:142::17]:42238) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uJuVi-000872-5h for submit@debbugs.gnu.org; Tue, 27 May 2025 09:38:30 -0400 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 1uJuVc-0001KY-4P for bug-gnu-emacs@gnu.org; Tue, 27 May 2025 09:38:24 -0400 Received: from mail-24417.protonmail.ch ([109.224.244.17]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uJuVW-0002rd-GA for bug-gnu-emacs@gnu.org; Tue, 27 May 2025 09:38:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1748353087; x=1748612287; bh=jFM6OxKATGtZMNoAZWOkJ46DWGe0g3QYrrKj0MeG050=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=mXXg4Nl1pz+Z4wDaZHQSE+aAqv4meEDNZmYuTVnwVVdncytJjiHlJcSQipNoUWpF3 jjFLUSBwt5NyqJYjQl+wXiY6gafDtNzqgipkK79z1NsdqTZ2fK74pPEnAX14ewQW5k OyLwwJxZwCZxs7Qmg5grM4nXn826mpo/bQv6grBivIdwMz/jt1utUpl2N1dQNQz5gR jTC+m48wSTrTA44pQQlvi21AfmA9iRVyfUz/tlfbfq2UN7Gx0TJhaG6F1vvSx3rA2s SJGpexx2SsYIcGaFDWh8Jom8z0+292OLlbJ4YcsXREkEkvqnl3j/76SIgA/Q0MrV4k SSzjmTWNxReuQ== Date: Tue, 27 May 2025 13:38:02 +0000 To: Andrea Corallo , bug-gnu-emacs@gnu.org From: Pip Cet Subject: 31.0.50; [nativecomp] native-ice in emit_mvar_rval Message-ID: <87v7pm6uoa.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 11a6fbcc8ca228401b1ecd3783815a3b8fa616c9 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=109.224.244.17; envelope-from=pipcet@protonmail.com; helo=mail-24417.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) 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: -0.0 (/) This reduced test case: ;; -*- lexical-binding: t; -*- (defun f (x) (and (=3D x 1) (if (eql x 1) 1 x))) causes a native-ice: Error: native-ice (\"can't find data in relocation containers\") when Emacs is run as: ./src/emacs -Q --batch --eval '(native-compile "native.el")' The problem, as far as I can see, is that emit_mvar_rval appears to assume that if the constraint part of an mvar allows only a single value, that value can also be fetched from the reloc array. In this case, the constraints on x make it so only 1.0 is a legal value in one basic block, but 1.0 isn't in the data array. Note that it is not a valid fix to make obj_to_reloc fail gently if it cannot find obj in either data container: if 1.0 is present in the ephemeral vector but not in the default vector, referring to the ephemeral vector after top_level_run has completed will fail. The problem is this limple insn: (set #(mvar 17592188503872 1 (member 1.0)) #(mvar 17592188503233 0 (member = 1.0))) The RHS mvar was not created with :constant 1.0 (so 1.0 was never added to the data container), but it is comp-cstr-imm-vld-p. The test case is reduced from mule-diag.el: (defun list-block-of-chars (charset row min max) (let (i ch) (insert-char ?- (+ 7 (* 4 16))) (insert "\n ") (setq i 0) (while (< i 16) (insert (format "%4X" i)) (setq i (1+ i))) (setq i (* (/ min 16) 16)) (while (<=3D i max) (if (=3D (% i 16) 0) =09 (insert (format "\n%6Xx" (/ (+ (* row 256) i) 16)))) (setq ch (if (< i min) =09=09 32 =09=09 (or (decode-char charset (+ (* row 256) i)) =09=09 32)))=09=09; gap in mapping ;; Don't insert control codes, non-Unicode characters. (if (or (< ch 32) (=3D ch 127)) =09 (setq ch (single-key-description ch)) =09(if (and (>=3D ch 128) (< ch 160)) =09 (setq ch (format "%02Xh" ch)) =09 (if (> ch #x10FFFF) =09 (setq ch 32)))) (insert "\t" ch) (setq i (1+ i)))) (insert "\n")) But the original problem in mule-diag.el (generating a basic block which would call (single-key-description 127.0) ) only showed up with other modifications to the nativecomp compiler. There are several ways to fix this, but I must note that adding a constant that is highly likely to be already present in the register file is usually wasteful: in this case, we don't want to create the constant 1.0, we simply want to return the register which we now know to contain 1.0. From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 07 04:42:11 2025 Received: (at 78606) by debbugs.gnu.org; 7 Jun 2025 08:42:11 +0000 Received: from localhost ([127.0.0.1]:46827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uNp7z-0005lL-71 for submit@debbugs.gnu.org; Sat, 07 Jun 2025 04:42:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54718) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uNp7x-0005l9-Mn for 78606@debbugs.gnu.org; Sat, 07 Jun 2025 04:42:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uNp7s-0005aI-Dn; Sat, 07 Jun 2025 04:42:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/cvnFRpUvn8++q+1rSehsp40pMilzUMH0+U+uQMuJoM=; b=ELj/JYyao9Lw yQWn88AUiPpzWKogL1DLfFN+bG1vIeYVKksNqe7UMa/Euhz7+kzeF13GldMNKRtsc89JU/lSX1llz oUfeuwkeFwKFe7BQy98q0JQWHebQYcws5vmj0GwtZ44qinU/6fLUHuQP6WF6jrjMtGvNgVVLepNIe 4U7jcyy9zaTXNA/3nRbkqjRT9dwaLV5lUSvTcKk+LK+VCAsL+QAmCF2WtBPxdTKuKozad/Zjfbb10 SqdXLAeSRbvFIabovmK4K8G0F9CU5/deLockZf0uccYgoSkRsMdINviFBbtwuCTSkWozD8S0ARWXX m4z8cXOftioF1xm19gcuXg==; Date: Sat, 07 Jun 2025 11:42:02 +0300 Message-Id: <86v7p8hrj9.fsf@gnu.org> From: Eli Zaretskii To: acorallo@gnu.org, Pip Cet In-Reply-To: <87v7pm6uoa.fsf@protonmail.com> (bug-gnu-emacs@gnu.org) Subject: Re: bug#78606: 31.0.50; [nativecomp] native-ice in emit_mvar_rval References: <87v7pm6uoa.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78606 Cc: 78606@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: -3.3 (---) Ping! Andrea, any comments or suggestions? > Date: Tue, 27 May 2025 13:38:02 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > This reduced test case: > > ;; -*- lexical-binding: t; -*- > > (defun f (x) > (and (= x 1) > (if (eql x 1) > 1 > x))) > > causes a native-ice: > > Error: native-ice (\"can't find data in relocation containers\") > > when Emacs is run as: > > ./src/emacs -Q --batch --eval '(native-compile "native.el")' > > The problem, as far as I can see, is that emit_mvar_rval appears to > assume that if the constraint part of an mvar allows only a single > value, that value can also be fetched from the reloc array. In this > case, the constraints on x make it so only 1.0 is a legal value in one > basic block, but 1.0 isn't in the data array. > > Note that it is not a valid fix to make obj_to_reloc fail gently if it > cannot find obj in either data container: if 1.0 is present in the > ephemeral vector but not in the default vector, referring to the > ephemeral vector after top_level_run has completed will fail. > > The problem is this limple insn: > > (set #(mvar 17592188503872 1 (member 1.0)) #(mvar 17592188503233 0 (member 1.0))) > > The RHS mvar was not created with :constant 1.0 (so 1.0 was never added > to the data container), but it is comp-cstr-imm-vld-p. > > The test case is reduced from mule-diag.el: > > (defun list-block-of-chars (charset row min max) > (let (i ch) > (insert-char ?- (+ 7 (* 4 16))) > (insert "\n ") > (setq i 0) > (while (< i 16) > (insert (format "%4X" i)) > (setq i (1+ i))) > (setq i (* (/ min 16) 16)) > (while (<= i max) > (if (= (% i 16) 0) > (insert (format "\n%6Xx" (/ (+ (* row 256) i) 16)))) > (setq ch (if (< i min) > 32 > (or (decode-char charset (+ (* row 256) i)) > 32))) ; gap in mapping > ;; Don't insert control codes, non-Unicode characters. > (if (or (< ch 32) (= ch 127)) > (setq ch (single-key-description ch)) > (if (and (>= ch 128) (< ch 160)) > (setq ch (format "%02Xh" ch)) > (if (> ch #x10FFFF) > (setq ch 32)))) > (insert "\t" ch) > (setq i (1+ i)))) > (insert "\n")) > > But the original problem in mule-diag.el (generating a basic block which > would call (single-key-description 127.0) ) only showed up with other > modifications to the nativecomp compiler. > > There are several ways to fix this, but I must note that adding a > constant that is highly likely to be already present in the register > file is usually wasteful: in this case, we don't want to create the > constant 1.0, we simply want to return the register which we now know to > contain 1.0. > > > > >