Received: (at 79782) by debbugs.gnu.org; 25 Nov 2025 20:17:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 25 15:17:02 2025 Received: from localhost ([127.0.0.1]:55365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vNzTA-0005DJ-3b for submit <at> debbugs.gnu.org; Tue, 25 Nov 2025 15:17:02 -0500 Received: from [109.224.244.17] (port=16275 helo=mail-24417.protonmail.ch) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vMP6d-00051h-I7 for 79782 <at> debbugs.gnu.org; Fri, 21 Nov 2025 06:15:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1763723699; x=1763982899; bh=DlzGGGN2SvXN+7JeYQ7gHjgGcNiyWXX2hhOQOQd/gqc=; 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; b=g/ea7URf7f7G3aGlGrFwL1Z3GYfJG2SmGe2wmradGwqBG7OqQuTy0QMfyErk/sR3A V1/zJ/9H3xYGJXLJc7awHUXRnM35Dcz9LMS25ZHYgl3o3Bsj/p5AOfrOZxa+jgJtx/ W13WNLALU60K6zRnwM2jQT72aOrR+0A5fmFizZUG6FTCC2y4LFqpe8Yy6aseNsyqHm eCtJWVJt2wCmJEXSvA/ZdmGBT9jCn18uvwan4IR8VRH8BIU7qR1I1yTfcPCRtSMXFO jh/cp4R96ur/iBB+KyvbRPUBDPcXd/ARy5DVv60OythWu0/1iymevAslzyxb/Ic2VM JyBpydy+Qk8Eg== Date: Fri, 21 Nov 2025 11:14:54 +0000 To: Andrea Corallo <acorallo@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete Message-ID: <87fra7ab88.fsf@HIDDEN> In-Reply-To: <yp1ldk6fhhq.fsf@HIDDEN> References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN> <m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN> <m2ms4xogu7.fsf@HIDDEN> <871pm91w33.fsf@HIDDEN> <m2frapobv5.fsf@HIDDEN> <87v7jlx7iw.fsf@HIDDEN> <86ecq89alm.fsf@HIDDEN> <yp1ldk6fhhq.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c7b31c6b680efcfc6188119070babbaca66f4cc1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: "Andrea Corallo" writes: > Eli Zaretskii writes: > >>> Cc: 79782 <at> debbugs.gnu.org >>> Date: Sat, 08 Nov 2025 08:17:48 +0000 >>> From: Pip Cet via "Bug reports for GNU Emacs, >>> the Swiss army knife of text editors" >> >> [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 T_SPF_HELO_TEMPERROR SPF: test of HELO record failed (temperror) 0.0 T_SPF_TEMPERROR SPF: test of record failed (temperror) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pipcet[at]protonmail.com) 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS 0.0 SPOOFED_FREEMAIL_NO_RDNS From SPOOFED_FREEMAIL and no rDNS X-Debbugs-Envelope-To: 79782 Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79782 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.3 (/) "Andrea Corallo" <acorallo@HIDDEN> writes: > Eli Zaretskii <eliz@HIDDEN> writes: > >>> Cc: 79782 <at> debbugs.gnu.org >>> Date: Sat, 08 Nov 2025 08:17:48 +0000 >>> From: Pip Cet via "Bug reports for GNU Emacs, >>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> Let's bring Andrea on-board of this discussion. >> > > Pip's patch looks like a very good idea to me. If he's confident it's > ready I think should go to master. Let's make that "if and when". The reason I'm not confident at this point is that we still want to support constructs like #1=3D(#1# . #1#), but they are rare and more tests would definitely be a good thing! > Also we might want to add to the patch few more tests to it like the > folowing? > > (ert-deftest lread-dag-sharing () > (let* ((s "#1=3D(\"x\" . #2=3D(a b)) (z . #2#) (w . #1#)") > (obj (car (read-from-string (format "(%s)" s))))) > (pcase-let* ((`(,p1 ,p2 ,p3) obj)) > (should (eq (cdr p1) (cdr p2))) > (should (eq (car p1) (car p3))) > (should (string=3D (car p1) "x"))))) > > (ert-deftest lread-text-props-with-sharing () > (let* ((s (propertize "x" 'p t)) > (form (list '#1=3D s (list '#2=3D '(a) '#1#) '#2#)) > (printed (prin1-to-string form)) > (read-back (read-from-string printed))) > (should (equal (car read-back) "x")) > (should (eq (cadr (cadr read-back)) (car read-back))) ; sharing > (should (get-text-property 0 'p (car read-back))))) > > (ert-deftest lread-nonlist-collections () > (let* ((ht (make-hash-table :test 'eq)) > (v (vector '#1=3D(a . b) '#1#)) > (_ (puthash 'k v ht)) > (printed (prin1-to-string (list ht v))) > (rb (read-from-string printed))) > (should (eq (aref (cdr rb) 0) (aref (gethash 'k (car rb)) 0))) ; shar= ing > (should (eq (aref (cdr rb) 0) (aref (cdr rb) 1))))) > > (ert-deftest lread-no-placeholder-leak () > (let* ((s "#1=3D(a b c) #1#") > (obj (read-from-string (format "(%s)" s)))) > (cl-labels ((scan (x) > (cond ((consp x) (should (not (eq (car x) 'placeholder)= )) The idea of my patch was that Qplaceholder would be an uninterned symbol (like Qunbound), so it would never eq 'placeholder, IIUC. So I'd prefer (should-not (and (symbolp (car x)) (equal (symbol-name (car x) "placeholder")))) here, I think. > (scan (car x)) (scan (cdr x))) > ((vectorp x) (mapc #'scan x)) > ((hash-table-p x) (maphash (lambda (k v) (scan k)= (scan v)) x))))) > (scan (car obj))))) > > > Andrea Thanks! Maybe we should start by including these tests (as XFAILs where appropriate)? Pip
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.
Received: (at 79782) by debbugs.gnu.org; 16 Nov 2025 09:34:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 16 04:34:54 2025
Received: from localhost ([127.0.0.1]:42885 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vKZ9q-0004nN-G0
for submit <at> debbugs.gnu.org; Sun, 16 Nov 2025 04:34:54 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:34190)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <acorallo@HIDDEN>) id 1vKZ9o-0004nD-8o
for 79782 <at> debbugs.gnu.org; Sun, 16 Nov 2025 04:34:52 -0500
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 <acorallo@HIDDEN>)
id 1vKZ9h-0001tz-KO; Sun, 16 Nov 2025 04:34:47 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
From; bh=n+Y8L3l3n/QBdxcvkrQXAElN9jMNhxE9dHa0hgPJXDI=; b=PrSpYYrmOayYldxKTpsq
hFidsVmJH+CXrBZ2Zgm06pCMCf9g1Yd+WmF0HAMQTrHWB7qhDSJmKqA9gF3y7dtVTl+Hd95JBAVNd
W74kxIHgmskCPpETCFJpZlkXqsojlBEM15vEnmdNtc36FCaGDqHIg6PCfDTwVU+mvDfx0p+g9Ablu
Nm9IUulJej67+rJIrC6kTaAxtIZQjMrV96s3KLc4oGGyd28hUHMz0z4FIqUbiVCzLpwbLPf1zFyCm
o1iPgvjTDazyGYkRvpp/X2EZ76TcQvlItRN9mS+sPvYPfjfWXCmZNHqubxYTlIgsMfIIMHWuZSykf
USScS0kLmIzLRA==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
(envelope-from <acorallo@HIDDEN>)
id 1vKZ9d-0000u2-A7; Sun, 16 Nov 2025 04:34:43 -0500
From: Andrea Corallo <acorallo@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not
complete
In-Reply-To: <86ecq89alm.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 08 Nov
2025 10:45:09 +0200")
References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN>
<m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN>
<m2ms4xogu7.fsf@HIDDEN> <871pm91w33.fsf@HIDDEN>
<m2frapobv5.fsf@HIDDEN> <87v7jlx7iw.fsf@HIDDEN>
<86ecq89alm.fsf@HIDDEN>
Date: Sun, 16 Nov 2025 04:34:41 -0500
Message-ID: <yp1ldk6fhhq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79782
Cc: gerd.moellmann@HIDDEN, Pip Cet <pipcet@HIDDEN>,
79782 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Eli Zaretskii <eliz@HIDDEN> writes:
>> Cc: 79782 <at> debbugs.gnu.org
>> Date: Sat, 08 Nov 2025 08:17:48 +0000
>> From: Pip Cet via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> Let's bring Andrea on-board of this discussion.
>
Pip's patch looks like a very good idea to me. If he's confident it's
ready I think should go to master.
Also we might want to add to the patch few more tests to it like the
folowing?
(ert-deftest lread-dag-sharing ()
(let* ((s "#1=(\"x\" . #2=(a b)) (z . #2#) (w . #1#)")
(obj (car (read-from-string (format "(%s)" s)))))
(pcase-let* ((`(,p1 ,p2 ,p3) obj))
(should (eq (cdr p1) (cdr p2)))
(should (eq (car p1) (car p3)))
(should (string= (car p1) "x")))))
(ert-deftest lread-text-props-with-sharing ()
(let* ((s (propertize "x" 'p t))
(form (list '#1= s (list '#2= '(a) '#1#) '#2#))
(printed (prin1-to-string form))
(read-back (read-from-string printed)))
(should (equal (car read-back) "x"))
(should (eq (cadr (cadr read-back)) (car read-back))) ; sharing
(should (get-text-property 0 'p (car read-back)))))
(ert-deftest lread-nonlist-collections ()
(let* ((ht (make-hash-table :test 'eq))
(v (vector '#1=(a . b) '#1#))
(_ (puthash 'k v ht))
(printed (prin1-to-string (list ht v)))
(rb (read-from-string printed)))
(should (eq (aref (cdr rb) 0) (aref (gethash 'k (car rb)) 0))) ; sharing
(should (eq (aref (cdr rb) 0) (aref (cdr rb) 1)))))
(ert-deftest lread-no-placeholder-leak ()
(let* ((s "#1=(a b c) #1#")
(obj (read-from-string (format "(%s)" s))))
(cl-labels ((scan (x)
(cond ((consp x) (should (not (eq (car x) 'placeholder)))
(scan (car x)) (scan (cdr x)))
((vectorp x) (mapc #'scan x))
((hash-table-p x) (maphash (lambda (k v) (scan k) (scan v)) x)))))
(scan (car obj)))))
Andrea
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.
Received: (at 79782) by debbugs.gnu.org; 16 Nov 2025 09:02:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 16 04:02:22 2025
Received: from localhost ([127.0.0.1]:42628 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vKYeL-0003Of-Ns
for submit <at> debbugs.gnu.org; Sun, 16 Nov 2025 04:02:22 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:37230)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <acorallo@HIDDEN>) id 1vKYeJ-0003OX-FG
for 79782 <at> debbugs.gnu.org; Sun, 16 Nov 2025 04:02:19 -0500
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 <acorallo@HIDDEN>)
id 1vKYeE-0004bX-3K; Sun, 16 Nov 2025 04:02:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Date:References:In-Reply-To:Subject:To:
From; bh=TYoq396AMdrDFkgGF4Aw+ScuKFsJ4qbjT+0XqRPe3iA=; b=MQlLlSv1LB2lJVzZ81ZY
HrRvApiLoKga+h8p9Ky1/BD1PgU6gVTsPn7pOxWVsSnpK88vqCY6ouIgA9nsiypVLoyk17QKKJey1
1OibVvM0e8OIx6MS/rcUW60+2UrZgjkS38dvQr1HyWsKd+L8ZSqF4l1qvxhEribk8aB4zd3RMp+cQ
q62NrEWOw3sl/yftIJwOk+MD45TyVlmPrYKohNsTP1Iwum1TN3R2cUS1sfXYjjkrV4RxfSbWKeZaZ
5bmDNB91rJJZk229sYnd0baSX4DYOvXyFsEG+2O5IxQxirQomHHV08WIeSp9l5uy80H1B2eu0p+OA
7QzB4RvI/rY6Wg==;
Received: from acorallo by fencepost.gnu.org with local (Exim 4.90_1)
(envelope-from <acorallo@HIDDEN>)
id 1vKYeC-0006fx-Je; Sun, 16 Nov 2025 04:02:13 -0500
From: Andrea Corallo <acorallo@HIDDEN>
To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not
complete
In-Reply-To: <m2frapobv5.fsf@HIDDEN> ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?=
=?utf-8?Q?s?= message of "Fri, 07 Nov 2025 20:56:30 +0100")
References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN>
<m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN>
<m2ms4xogu7.fsf@HIDDEN> <871pm91w33.fsf@HIDDEN>
<m2frapobv5.fsf@HIDDEN>
Date: Sun, 16 Nov 2025 04:02:12 -0500
Message-ID: <yp1pl9ifizv.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79782
Cc: Pip Cet <pipcet@HIDDEN>, 79782 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Pip Cet <pipcet@HIDDEN> writes:
>
>>> Is it something the compilation process outputs? What the heck. I would
>>> never have expected anything like that. Not even that it does the
>>> compilation in another process.
>>
>> IIUC, the reason for the separate compilation process is that libgccjit
>> has memory leaks or crashes in too many versions. Best to use a separate
>> process for it.
>
> Yeah, I meanwhile found this:
>
> comp.el:
> 3335 (defun comp--final (_)
> 3336 "Final pass driving the C back-end for code emission."
> 3337 (unless comp-dry-run
> 3338 ;; Always run the C side of the compilation as a sub-process
> 3339 ;; unless during bootstrap or async compilation (bug#45056). G=
CC
> 3340 ;; leaks memory but also interfere with the ability of Emacs to
> 3341 ;; detect when a sub-process completes (TODO understand why).
> 3342 (if (or comp-running-batch-compilation comp-async-compilation)
> 3343 (comp--final1)
> 3344 ;; Call comp--final1 in a child process.
>
> Didn't follow the expensive case in the following lines.
>
> The comment if from 2020-07. Maybe this is longer necessary? How knows.
> Not so good for a library.
AFAIU it is still necessary.
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.
Received: (at 79782) by debbugs.gnu.org; 8 Nov 2025 08:45:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 03:45:49 2025
Received: from localhost ([127.0.0.1]:50581 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHeZw-0002zR-46
for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:45:49 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:46232)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHeZu-0002zH-3Z
for 79782 <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:45:47 -0500
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 <eliz@HIDDEN>)
id 1vHeZl-0001o8-UV; Sat, 08 Nov 2025 03:45:40 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=GsP6x4y5L0idpN1NaRT0Lr/277K5wpDUNI4NbYpEfM8=; b=V2bBJW++VDC3W7taOPjw
lKP60m334YNJ7zC4nknlI4+gX4803Ci06s0Jnm6BOqzAzH41KYjjPCuan5taw/zADNwFn54jzqD8X
9SQTGBlPPbD6whA6VatDJnmyp4yChKZhpdmtXlxuHLxStVliu+OpKbyRFjH5qzbP0lenrflWztDar
VgdrYYGTdQjH0Q5xstBRSlCUcBHIqIDj/t45IzaDvKN3DYGWqOuLa58jTRnoO3/2I5L2canuIf+Zy
9nXF798WgE8E9F9jua/3Vk8Z4/O5BJ2SO2RhalQaO1rssdhkym8r3CmNmJU6jeGv1RqiLPwkTbl4u
XW1ts1ct703JCw==;
Date: Sat, 08 Nov 2025 10:45:09 +0200
Message-Id: <86ecq89alm.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>,
Andrea Corallo <acorallo@HIDDEN>
In-Reply-To: <87v7jlx7iw.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#79782: 31.0.50;
M-x emacs-lisp-native-compile does not complete
References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN>
<m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN>
<m2ms4xogu7.fsf@HIDDEN> <871pm91w33.fsf@HIDDEN>
<m2frapobv5.fsf@HIDDEN> <87v7jlx7iw.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79782
Cc: gerd.moellmann@HIDDEN, 79782 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Cc: 79782 <at> debbugs.gnu.org
> Date: Sat, 08 Nov 2025 08:17:48 +0000
> From: Pip Cet via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
Let's bring Andrea on-board of this discussion.
> Gerd Möllmann <gerd.moellmann@HIDDEN> writes:
>
> > Pip Cet <pipcet@HIDDEN> writes:
> >
> >>> Is it something the compilation process outputs? What the heck. I would
> >>> never have expected anything like that. Not even that it does the
> >>> compilation in another process.
> >>
> >> IIUC, the reason for the separate compilation process is that libgccjit
> >> has memory leaks or crashes in too many versions. Best to use a separate
> >> process for it.
> >
> > Yeah, I meanwhile found this:
> >
> > comp.el:
> > 3335 (defun comp--final (_)
> > 3336 "Final pass driving the C back-end for code emission."
> > 3337 (unless comp-dry-run
> > 3338 ;; Always run the C side of the compilation as a sub-process
> > 3339 ;; unless during bootstrap or async compilation (bug#45056). GCC
> > 3340 ;; leaks memory but also interfere with the ability of Emacs to
> > 3341 ;; detect when a sub-process completes (TODO understand why).
> > 3342 (if (or comp-running-batch-compilation comp-async-compilation)
> > 3343 (comp--final1)
> > 3344 ;; Call comp--final1 in a child process.
> >
> > Didn't follow the expensive case in the following lines.
> >
> > The comment if from 2020-07. Maybe this is longer necessary? How knows.
> > Not so good for a library.
> >
> >
> >>
> >>> Anyway. Thanks, and I guess I should close this then.
> >>
> >> I'm not sure. Both the performance and the recursion depth of
> >> Flread__substitute_object_in_subtree seem worrying to me.
> >
> > Please re-open as you see fit.
> >
> >>
> >> Without a patch, without compilation, and on this somewhat outdated
> >> machine (likely much faster on Apple Silicon), I get:
> >>
> >> $ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lisp-native-compile)'
> >>
> >> real 9m58.466s
> >> user 9m56.942s
> >> sys 0m0.663s
> >>
> >> With some spur-of-the-moment patching, I get:
> >>
> >> $ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lisp-native-compile)'
> >>
> >> real 0m49.738s
> >> user 0m49.172s
> >> sys 0m0.488s
> >>
> >> Assuming this isn't an -felide-function-bodies
> >> (https://gcc.gnu.org/pipermail/gcc/2017-April/223035.html) style
> >> optimization, we should probably do something like it, with a heuristic
> >> for when to switch to the "seen" hash table.
> >
> > Makes a lot of sense to me.
> >
> > I guess someone should also check what's up with libgccjit, but that's
> > another independent story.
>
> Just because I did mess up (the first patch didn't preserve CDR cells
> that were substituted), here's the current version. The major change is
> based on the observation that most objects are not actually defined
> using a cycle, they're defined normally and referenced more than
> once. No need to substitute anything for those. It also makes #1=#2=#1#
> an error, since we need to be more careful about that if we don't want
> our placeholders to leak to Lisp.
>
> >From 78bc3c57a2dd9cce740527169c1a7d9ed70c2de2 Mon Sep 17 00:00:00 2001
> From: Pip Cet <pipcet@HIDDEN>
> Date: Fri, 7 Nov 2025 22:08:08 +0000
> Subject: [PATCH] Improve performance of #N# substitution (bug#79782)
>
> Previously, we'd substitute a placeholder element recursively even if
> it wasn't used. Now, we keep a count of how often the placeholder was
> reused, and perform only the right number of substitutions.
>
> Also, catch silly games like #1=#2=#1#.
>
> * src/lread.c (struct subst): New field 'n' for number of
> substitutions to be performed.
> (read0): Use new placeholders. Simplify code and only call
> 'Flread__substitute_object_in_subtree' if actually necessary.
> (Flread__substitute_object_in_subtree):
> (substitute_object_recurse): Keep track of number of
> substitutions. Use a hash table rather than a list for the 'seen'
> field if there are many substitutions.
> (init_lread): Unintern 'Qplaceholder', which is internal (like
> 'Qunbound').
> (syms_of_lread): Declare 'Qplaceholder'.
> * test/src/lread-tests.el (lread-circle): New test for "#1=#2=#1#".
> ---
> src/lread.c | 94 ++++++++++++++++++++---------------------
> test/src/lread-tests.el | 3 +-
> 2 files changed, 49 insertions(+), 48 deletions(-)
>
> diff --git a/src/lread.c b/src/lread.c
> index 9c4da863363..38bd48f1c62 100644
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -735,6 +735,9 @@ read_emacs_mule_char (source_t *src, int c)
>
> /* List of subobjects of OBJECT that have already been visited. */
> Lisp_Object seen;
> +
> + /* How many substitutions left to perform, or -1 if unknown. */
> + ptrdiff_t n;
> };
>
> static Lisp_Object read_internal_start (Lisp_Object, Lisp_Object,
> @@ -4034,7 +4037,7 @@ read0 (source_t *source, bool locate_syms)
> if (c == '=')
> {
> /* #N=OBJ -- assign number N to OBJ */
> - Lisp_Object placeholder = Fcons (Qnil, Qnil);
> + Lisp_Object placeholder = Fcons (Qplaceholder, make_fixnum (0));
>
> struct Lisp_Hash_Table *h
> = XHASH_TABLE (read_objects_map);
> @@ -4062,6 +4065,8 @@ read0 (source_t *source, bool locate_syms)
> if (i < 0)
> invalid_syntax_with_buffer (&rb, source);
> obj = HASH_VALUE (h, i);
> + if (CONSP (obj) && BASE_EQ (XCAR (obj), Qplaceholder))
> + XSETCDR (obj, make_fixnum (XFIXNUM (XCDR (obj)) + 1));
> break;
> }
> else
> @@ -4322,29 +4327,10 @@ read0 (source_t *source, bool locate_syms)
> {
> read_stack_pop ();
> Lisp_Object placeholder = e->u.numbered.placeholder;
> - if (CONSP (obj))
> - {
> - if (BASE_EQ (obj, placeholder))
> - /* Catch silly games like #1=#1# */
> - invalid_syntax ("nonsensical self-reference", source);
> -
> - /* Optimization: since the placeholder is already
> - a cons, repurpose it as the actual value.
> - This allows us to skip the substitution below,
> - since the placeholder is already referenced
> - inside OBJ at the appropriate places. */
> - Fsetcar (placeholder, XCAR (obj));
> - Fsetcdr (placeholder, XCDR (obj));
> -
> - struct Lisp_Hash_Table *h2
> - = XHASH_TABLE (read_objects_completed);
> - hash_hash_t hash;
> - ptrdiff_t i = hash_find_get_hash (h2, placeholder, &hash);
> - eassert (i < 0);
> - hash_put (h2, placeholder, Qnil, hash);
> - obj = placeholder;
> - }
> - else
> + /* Catch silly games like #1=#2=#1#. */
> + if (BASE_EQ (placeholder, obj))
> + invalid_syntax ("nonsensical self-reference", source);
> + if (XFIXNUM (XCDR (placeholder)) > 0)
> {
> /* If it can be recursive, remember it for future
> substitutions. */
> @@ -4361,16 +4347,17 @@ read0 (source_t *source, bool locate_syms)
>
> /* Now put it everywhere the placeholder was... */
> Flread__substitute_object_in_subtree (obj, placeholder,
> - read_objects_completed);
> -
> - /* ...and #n# will use the real value from now on. */
> - struct Lisp_Hash_Table *h = XHASH_TABLE (read_objects_map);
> - hash_hash_t hash;
> - ptrdiff_t i = hash_find_get_hash (h, e->u.numbered.number,
> - &hash);
> - eassert (i >= 0);
> - set_hash_value_slot (h, i, obj);
> + read_objects_completed,
> + XCDR (placeholder));
> }
> +
> + /* ...and #n# will use the real value from now on. */
> + struct Lisp_Hash_Table *h = XHASH_TABLE (read_objects_map);
> + hash_hash_t hash;
> + ptrdiff_t i = hash_find_get_hash (h, e->u.numbered.number,
> + &hash);
> + eassert (i >= 0);
> + set_hash_value_slot (h, i, obj);
> break;
> }
> }
> @@ -4382,28 +4369,32 @@ read0 (source_t *source, bool locate_syms)
>
> DEFUN ("lread--substitute-object-in-subtree",
> Flread__substitute_object_in_subtree,
> - Slread__substitute_object_in_subtree, 3, 3, 0,
> + Slread__substitute_object_in_subtree, 3, 4, 0,
> doc: /* In OBJECT, replace every occurrence of PLACEHOLDER with OBJECT.
> COMPLETED is a hash table of objects that might be circular, or is t
> -if any object might be circular. */)
> - (Lisp_Object object, Lisp_Object placeholder, Lisp_Object completed)
> +if any object might be circular. Stop after NSUBST substitutions. */)
> + (Lisp_Object object, Lisp_Object placeholder, Lisp_Object completed,
> + Lisp_Object nsubst)
> {
> - struct subst subst = { object, placeholder, completed, Qnil };
> - Lisp_Object check_object = substitute_object_recurse (&subst, object);
> -
> - /* The returned object here is expected to always eq the
> - original. */
> - if (!EQ (check_object, object))
> - error ("Unexpected mutation error in reader");
> - return Qnil;
> + ptrdiff_t n = FIXNUMP (nsubst) ? XFIXNUM (nsubst) : -1;
> + Lisp_Object seen = ((n >= 0 && n < 16) ? Qnil :
> + CALLN (Fmake_hash_table, QCtest, Qeq));
> + struct subst subst = { object, placeholder, completed, seen, n };
> + return substitute_object_recurse (&subst, object);
> }
>
> static Lisp_Object
> substitute_object_recurse (struct subst *subst, Lisp_Object subtree)
> {
> + if (subst->n == 0)
> + return subtree;
> +
> /* If we find the placeholder, return the target object. */
> if (EQ (subst->placeholder, subtree))
> - return subst->object;
> + {
> + subst->n--;
> + return subst->object;
> + }
>
> /* For common object types that can't contain other objects, don't
> bother looking them up; we're done. */
> @@ -4413,7 +4404,8 @@ substitute_object_recurse (struct subst *subst, Lisp_Object subtree)
> return subtree;
>
> /* If we've been to this node before, don't explore it again. */
> - if (!NILP (Fmemq (subtree, subst->seen)))
> + if (!NILP (HASH_TABLE_P (subst->seen) ? Fgethash (subtree, subst->seen, Qnil)
> + : Fmemq (subtree, subst->seen)))
> return subtree;
>
> /* If this node can be the entry point to a cycle, remember that
> @@ -4422,7 +4414,12 @@ substitute_object_recurse (struct subst *subst, Lisp_Object subtree)
> COMPLETED. */
> if (EQ (subst->completed, Qt)
> || hash_find (XHASH_TABLE (subst->completed), subtree) >= 0)
> - subst->seen = Fcons (subtree, subst->seen);
> + {
> + if (HASH_TABLE_P (subst->seen))
> + Fputhash (subtree, Qt, subst->seen);
> + else
> + subst->seen = Fcons (subtree, subst->seen);
> + }
>
> /* Recurse according to subtree's type.
> Every branch must return a Lisp_Object. */
> @@ -5522,6 +5519,8 @@ init_lread (void)
> Vload_true_file_name = Qnil;
> Vstandard_input = Qt;
> Vloads_in_progress = Qnil;
> +
> + Funintern (Qplaceholder, Qnil);
> }
>
> /* Print a warning that directory intended for use USE and with name
> @@ -5931,4 +5930,5 @@ syms_of_lread (void)
> DEFSYM (Qinternal_macroexpand_for_load,
> "internal-macroexpand-for-load");
> DEFSYM (Qread_minibuffer, "read-minibuffer");
> + DEFSYM (Qplaceholder, "placeholder");
> }
> diff --git a/test/src/lread-tests.el b/test/src/lread-tests.el
> index d1320a665a5..d1d040f2131 100644
> --- a/test/src/lread-tests.el
> +++ b/test/src/lread-tests.el
> @@ -309,7 +309,8 @@ lread-circle
> (dolist (str lread-test-circle-cases)
> (ert-info (str :prefix "input: ")
> (should (equal (lread-test-read-and-print str) str))))
> - (should-error (read-from-string "#1=#1#") :type 'invalid-read-syntax))
> + (should-error (read-from-string "#1=#1#") :type 'invalid-read-syntax)
> + (should-error (read-from-string "#1=#2=#1#") :type 'invalid-read-syntax))
>
> (ert-deftest lread-deeply-nested ()
> ;; Check that we can read a deeply nested data structure correctly.
> --
> 2.51.1
>
>
>
>
>
>
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.Received: (at 79782) by debbugs.gnu.org; 8 Nov 2025 08:26:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 03:26:37 2025 Received: from localhost ([127.0.0.1]:50517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHeHM-00020z-R9 for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:26:37 -0500 Received: from mail-ed1-x52c.google.com ([2a00:1450:4864:20::52c]:42253) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vHeHK-00020b-Ii for 79782 <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:26:35 -0500 Received: by mail-ed1-x52c.google.com with SMTP id 4fb4d7f45d1cf-63c489f1e6cso1894233a12.1 for <79782 <at> debbugs.gnu.org>; Sat, 08 Nov 2025 00:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762590388; x=1763195188; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=xEqIOVakpLtTvV5cKk0i+++On0+zAtLgSZ5MXOVj2jw=; b=evuWO10mc2/qjQqBgSQbZLHBzBv/CQxIo+ihTBnUEzE7+1rHomFAN0lfTw2Dsk4fzB Pqv/Lg6jyA47NYMawMbxh6AqJS4kSZDiZzxxOmMCaOTyjA2nWv2wHY1QtB2iJCZx/+rL CiOj1eCbYOXU6vyYVqrMCdGnTgV1uwDjCBZJgtyJa+5emKpzHEvluMSq/PXcUkG5VotP CdDdlKpLvlh5HJYhufZ2KXMqZjuhupNxLZH33UcPurTCvm7ufncI0d+He+3+GyZ3+mmD olWSQjnAnq5MDWKgsHjETFFLxyBd6YUj3x787+SK6SDgNnHTw7sQr7QAGX4ShrEiYUHp TSPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762590388; x=1763195188; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=xEqIOVakpLtTvV5cKk0i+++On0+zAtLgSZ5MXOVj2jw=; b=uPzi5h83hJ4Zmwt+IIUBB2V4FFtjEnebQG1ZqJQF4GRW5WvMg4kNF2T5iSq5rD1aDb JTI+xhRKn+yjBI4eSyo3QlejVbz/3xQJYVGG02XvLvaLxEbaiZ99C3MdvX0UNZU+RG/h Y8agU+Wm4sYo/Zif397tYbh2D9MOUEzDRIWyHDjEHCCR8Dno8vYAx0tE8I/ZdteV4SrH +LrE2N9X0RpnWkVEmfyxxp8JgzZ9a1AhuON4i3jnOcdbECkbXZeFZufM3xHoH01DiVsO eShixmYBGlv5Phb7mn/RPzeFMAH3+CAkK7K32WbcFX001WTzYz2ULMACm6c6QsT88kjC 1uOA== X-Gm-Message-State: AOJu0YxevJStM0s5Nt1/hGNdRuImU9uofRWbNkPHtyj1I23QIT6/lAUn Hpoi8p+T3/aJR+T313w8JXTZrz6iZIdYgITUsqUyVGE4MABESly3R20asNiZFK39 X-Gm-Gg: ASbGnctzjxhZ78+58kFbrjVXTAVHQOqbU0zXE3GEl5ZbfnUuuLETPG+aEsgX2oV6dhF rcjAiFs4dT07SGvI6q54LgBAPjCir8I3ILJJeqvGYY8mFdztC6GpzSqd/4jO3T3Fx9pBSv+jk/Z gYFRevW9BKLN76dEef6txe59Zmj9tMAftLuPjFH1thWTjvgzcR5yVNpQEoz05TEJbtSrb71vVIP bycA8Pc6XFGrsKZxP8aXnFkRi/BZZL/F5ML/R+5fjY8/FFkw4pXbmL2/qY2nh5E46J8pe0dU9MP gP0q39n9pYByCSmevot2zBzsN2uIICs/+OaT6OTiLzAO/9v3KIlgI/sEeo3PNDKNrNvIfHGqmWp mXwINgAMoak07pbsAnlhmmS5tuAVBwxgVayHSwTdBMx6ayhqI85sji77M4EHMdauSsf0CTeKzCn gPo7nbuytgjM1VXt4c22MgCeRThdaMiXx3Q3/kpFtWXok659Pb65mSdUFBr/KWQgfXfpIEiqSoV 6R14+AC7pb/zhXCPvI9yGyECM6DKrJxKg== X-Google-Smtp-Source: AGHT+IH6IkGdHFLcvcvsxUFRLTVK/I4RM8sM4lFxDb1jzaev/dmXQ33E5zCPOEgY6rTEi8ARWJ5Odw== X-Received: by 2002:a05:6402:2105:b0:640:ca33:81ac with SMTP id 4fb4d7f45d1cf-6415a278754mr2181368a12.13.1762590387812; Sat, 08 Nov 2025 00:26:27 -0800 (PST) Received: from pro4 (p200300e0b7172900909ecbe2ac26ed0b.dip0.t-ipconnect.de. [2003:e0:b717:2900:909e:cbe2:ac26:ed0b]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-641654e5592sm810237a12.19.2025.11.08.00.26.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Nov 2025 00:26:26 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete In-Reply-To: <87v7jlx7iw.fsf@HIDDEN> References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN> <m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN> <m2ms4xogu7.fsf@HIDDEN> <871pm91w33.fsf@HIDDEN> <m2frapobv5.fsf@HIDDEN> <87v7jlx7iw.fsf@HIDDEN> Date: Sat, 08 Nov 2025 09:26:25 +0100 Message-ID: <m2346pnd5a.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79782 Cc: 79782 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Pip Cet <pipcet@HIDDEN> writes: >> Makes a lot of sense to me. >> >> I guess someone should also check what's up with libgccjit, but that's >> another independent story. > > Just because I did mess up (the first patch didn't preserve CDR cells > that were substituted), here's the current version. Thanks, I like that a lot! (Maybe I steal that before it lands :-)).
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.
Received: (at 79782) by debbugs.gnu.org; 8 Nov 2025 08:18:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 03:18:05 2025
Received: from localhost ([127.0.0.1]:50498 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHe96-0001dX-64
for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:18:04 -0500
Received: from mail-10631.protonmail.ch ([79.135.106.31]:47691)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHe93-0001d8-72
for 79782 <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:18:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762589873; x=1762849073;
bh=ielgOVRsYt2H+d+5jczZKQRrB2oecIgrzIyAUG9szMc=;
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;
b=kEWUImCz2D47CyFbOxZr+uTYRFGhcYBWWiKjyIPn17GXoX5by0hJ/Y75LLNkUA19B
IQ1oQrcqlnBcw3jYHHT3a3NhV6K/HdD4jO9khXcIA8luU50A/hJvh0WU93GzsTr17L
QaQBwcPzcB1QLYQE/reWm5NtUv5JQR/njn4fXVo4f6Ga0vyeAnIhdm1u/j48BRZpzc
/ul7grx0uW5U0S7sqqZu+v6tbySVCsXITMNV4nOthfkRmjFmthrwnIFLJf0de0ReOh
2OSrQhU0XYjYBsXcB0rRdtCSNnPR1oVZEEUX/EMFvRKVhwywrqZ2virUHrbbLLAVf4
tVRR4uht4TQ+Q==
Date: Sat, 08 Nov 2025 08:17:48 +0000
To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79782: 31.0.50;
M-x emacs-lisp-native-compile does not complete
Message-ID: <87v7jlx7iw.fsf@HIDDEN>
In-Reply-To: <m2frapobv5.fsf@HIDDEN>
References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN>
<m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN>
<m2ms4xogu7.fsf@HIDDEN> <871pm91w33.fsf@HIDDEN>
<m2frapobv5.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: ba7501858a23b1853d37d49b5dfd4cae293ac319
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: 79782
Cc: 79782 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Pip Cet <pipcet@HIDDEN> writes:
>
>>> Is it something the compilation process outputs? What the heck. I would
>>> never have expected anything like that. Not even that it does the
>>> compilation in another process.
>>
>> IIUC, the reason for the separate compilation process is that libgccjit
>> has memory leaks or crashes in too many versions. Best to use a separate
>> process for it.
>
> Yeah, I meanwhile found this:
>
> comp.el:
> 3335 (defun comp--final (_)
> 3336 "Final pass driving the C back-end for code emission."
> 3337 (unless comp-dry-run
> 3338 ;; Always run the C side of the compilation as a sub-process
> 3339 ;; unless during bootstrap or async compilation (bug#45056). G=
CC
> 3340 ;; leaks memory but also interfere with the ability of Emacs to
> 3341 ;; detect when a sub-process completes (TODO understand why).
> 3342 (if (or comp-running-batch-compilation comp-async-compilation)
> 3343 (comp--final1)
> 3344 ;; Call comp--final1 in a child process.
>
> Didn't follow the expensive case in the following lines.
>
> The comment if from 2020-07. Maybe this is longer necessary? How knows.
> Not so good for a library.
>
>
>>
>>> Anyway. Thanks, and I guess I should close this then.
>>
>> I'm not sure. Both the performance and the recursion depth of
>> Flread__substitute_object_in_subtree seem worrying to me.
>
> Please re-open as you see fit.
>
>>
>> Without a patch, without compilation, and on this somewhat outdated
>> machine (likely much faster on Apple Silicon), I get:
>>
>> $ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lis=
p-native-compile)'
>>
>> real 9m58.466s
>> user 9m56.942s
>> sys 0m0.663s
>>
>> With some spur-of-the-moment patching, I get:
>>
>> $ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lis=
p-native-compile)'
>>
>> real 0m49.738s
>> user 0m49.172s
>> sys 0m0.488s
>>
>> Assuming this isn't an -felide-function-bodies
>> (https://gcc.gnu.org/pipermail/gcc/2017-April/223035.html) style
>> optimization, we should probably do something like it, with a heuristic
>> for when to switch to the "seen" hash table.
>
> Makes a lot of sense to me.
>
> I guess someone should also check what's up with libgccjit, but that's
> another independent story.
Just because I did mess up (the first patch didn't preserve CDR cells
that were substituted), here's the current version. The major change is
based on the observation that most objects are not actually defined
using a cycle, they're defined normally and referenced more than
once. No need to substitute anything for those. It also makes #1=3D#2=3D#1#
an error, since we need to be more careful about that if we don't want
our placeholders to leak to Lisp.
From 78bc3c57a2dd9cce740527169c1a7d9ed70c2de2 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 7 Nov 2025 22:08:08 +0000
Subject: [PATCH] Improve performance of #N# substitution (bug#79782)
Previously, we'd substitute a placeholder element recursively even if
it wasn't used. Now, we keep a count of how often the placeholder was
reused, and perform only the right number of substitutions.
Also, catch silly games like #1=3D#2=3D#1#.
* src/lread.c (struct subst): New field 'n' for number of
substitutions to be performed.
(read0): Use new placeholders. Simplify code and only call
'Flread__substitute_object_in_subtree' if actually necessary.
(Flread__substitute_object_in_subtree):
(substitute_object_recurse): Keep track of number of
substitutions. Use a hash table rather than a list for the 'seen'
field if there are many substitutions.
(init_lread): Unintern 'Qplaceholder', which is internal (like
'Qunbound').
(syms_of_lread): Declare 'Qplaceholder'.
* test/src/lread-tests.el (lread-circle): New test for "#1=3D#2=3D#1#".
---
src/lread.c | 94 ++++++++++++++++++++---------------------
test/src/lread-tests.el | 3 +-
2 files changed, 49 insertions(+), 48 deletions(-)
diff --git a/src/lread.c b/src/lread.c
index 9c4da863363..38bd48f1c62 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -735,6 +735,9 @@ read_emacs_mule_char (source_t *src, int c)
=20
/* List of subobjects of OBJECT that have already been visited. */
Lisp_Object seen;
+
+ /* How many substitutions left to perform, or -1 if unknown. */
+ ptrdiff_t n;
};
=20
static Lisp_Object read_internal_start (Lisp_Object, Lisp_Object,
@@ -4034,7 +4037,7 @@ read0 (source_t *source, bool locate_syms)
=09=09 if (c =3D=3D '=3D')
=09=09 {
=09=09=09/* #N=3DOBJ -- assign number N to OBJ */
-=09=09=09Lisp_Object placeholder =3D Fcons (Qnil, Qnil);
+=09=09=09Lisp_Object placeholder =3D Fcons (Qplaceholder, make_fixnum (0))=
;
=20
=09=09=09struct Lisp_Hash_Table *h
=09=09=09 =3D XHASH_TABLE (read_objects_map);
@@ -4062,6 +4065,8 @@ read0 (source_t *source, bool locate_syms)
=09=09=09if (i < 0)
=09=09=09 invalid_syntax_with_buffer (&rb, source);
=09=09=09obj =3D HASH_VALUE (h, i);
+=09=09=09if (CONSP (obj) && BASE_EQ (XCAR (obj), Qplaceholder))
+=09=09=09 XSETCDR (obj, make_fixnum (XFIXNUM (XCDR (obj)) + 1));
=09=09=09break;
=09=09 }
=09=09 else
@@ -4322,29 +4327,10 @@ read0 (source_t *source, bool locate_syms)
=09 {
=09 read_stack_pop ();
=09 Lisp_Object placeholder =3D e->u.numbered.placeholder;
-=09 if (CONSP (obj))
-=09 {
-=09=09if (BASE_EQ (obj, placeholder))
-=09=09 /* Catch silly games like #1=3D#1# */
-=09=09 invalid_syntax ("nonsensical self-reference", source);
-
-=09=09/* Optimization: since the placeholder is already
-=09=09 a cons, repurpose it as the actual value.
-=09=09 This allows us to skip the substitution below,
-=09=09 since the placeholder is already referenced
-=09=09 inside OBJ at the appropriate places. */
-=09=09Fsetcar (placeholder, XCAR (obj));
-=09=09Fsetcdr (placeholder, XCDR (obj));
-
-=09=09struct Lisp_Hash_Table *h2
-=09=09 =3D XHASH_TABLE (read_objects_completed);
-=09=09hash_hash_t hash;
-=09=09ptrdiff_t i =3D hash_find_get_hash (h2, placeholder, &hash);
-=09=09eassert (i < 0);
-=09=09hash_put (h2, placeholder, Qnil, hash);
-=09=09obj =3D placeholder;
-=09 }
-=09 else
+=09 /* Catch silly games like #1=3D#2=3D#1#. */
+=09 if (BASE_EQ (placeholder, obj))
+=09 invalid_syntax ("nonsensical self-reference", source);
+=09 if (XFIXNUM (XCDR (placeholder)) > 0)
=09 {
=09=09/* If it can be recursive, remember it for future
=09=09 substitutions. */
@@ -4361,16 +4347,17 @@ read0 (source_t *source, bool locate_syms)
=20
=09=09/* Now put it everywhere the placeholder was... */
=09=09Flread__substitute_object_in_subtree (obj, placeholder,
-=09=09=09=09=09=09 read_objects_completed);
-
-=09=09/* ...and #n# will use the real value from now on. */
-=09=09struct Lisp_Hash_Table *h =3D XHASH_TABLE (read_objects_map);
-=09=09hash_hash_t hash;
-=09=09ptrdiff_t i =3D hash_find_get_hash (h, e->u.numbered.number,
-=09=09=09=09=09=09 &hash);
-=09=09eassert (i >=3D 0);
-=09=09set_hash_value_slot (h, i, obj);
+=09=09=09=09=09=09 read_objects_completed,
+=09=09=09=09=09=09 XCDR (placeholder));
=09 }
+
+=09 /* ...and #n# will use the real value from now on. */
+=09 struct Lisp_Hash_Table *h =3D XHASH_TABLE (read_objects_map);
+=09 hash_hash_t hash;
+=09 ptrdiff_t i =3D hash_find_get_hash (h, e->u.numbered.number,
+=09=09=09=09=09 &hash);
+=09 eassert (i >=3D 0);
+=09 set_hash_value_slot (h, i, obj);
=09 break;
=09 }
=09}
@@ -4382,28 +4369,32 @@ read0 (source_t *source, bool locate_syms)
=20
DEFUN ("lread--substitute-object-in-subtree",
Flread__substitute_object_in_subtree,
- Slread__substitute_object_in_subtree, 3, 3, 0,
+ Slread__substitute_object_in_subtree, 3, 4, 0,
doc: /* In OBJECT, replace every occurrence of PLACEHOLDER with OBJ=
ECT.
COMPLETED is a hash table of objects that might be circular, or is t
-if any object might be circular. */)
- (Lisp_Object object, Lisp_Object placeholder, Lisp_Object completed)
+if any object might be circular. Stop after NSUBST substitutions. */)
+ (Lisp_Object object, Lisp_Object placeholder, Lisp_Object completed,
+ Lisp_Object nsubst)
{
- struct subst subst =3D { object, placeholder, completed, Qnil };
- Lisp_Object check_object =3D substitute_object_recurse (&subst, object);
-
- /* The returned object here is expected to always eq the
- original. */
- if (!EQ (check_object, object))
- error ("Unexpected mutation error in reader");
- return Qnil;
+ ptrdiff_t n =3D FIXNUMP (nsubst) ? XFIXNUM (nsubst) : -1;
+ Lisp_Object seen =3D ((n >=3D 0 && n < 16) ? Qnil :
+=09=09 CALLN (Fmake_hash_table, QCtest, Qeq));
+ struct subst subst =3D { object, placeholder, completed, seen, n };
+ return substitute_object_recurse (&subst, object);
}
=20
static Lisp_Object
substitute_object_recurse (struct subst *subst, Lisp_Object subtree)
{
+ if (subst->n =3D=3D 0)
+ return subtree;
+
/* If we find the placeholder, return the target object. */
if (EQ (subst->placeholder, subtree))
- return subst->object;
+ {
+ subst->n--;
+ return subst->object;
+ }
=20
/* For common object types that can't contain other objects, don't
bother looking them up; we're done. */
@@ -4413,7 +4404,8 @@ substitute_object_recurse (struct subst *subst, Lisp_=
Object subtree)
return subtree;
=20
/* If we've been to this node before, don't explore it again. */
- if (!NILP (Fmemq (subtree, subst->seen)))
+ if (!NILP (HASH_TABLE_P (subst->seen) ? Fgethash (subtree, subst->seen, =
Qnil)
+=09 : Fmemq (subtree, subst->seen)))
return subtree;
=20
/* If this node can be the entry point to a cycle, remember that
@@ -4422,7 +4414,12 @@ substitute_object_recurse (struct subst *subst, Lisp=
_Object subtree)
COMPLETED. */
if (EQ (subst->completed, Qt)
|| hash_find (XHASH_TABLE (subst->completed), subtree) >=3D 0)
- subst->seen =3D Fcons (subtree, subst->seen);
+ {
+ if (HASH_TABLE_P (subst->seen))
+=09Fputhash (subtree, Qt, subst->seen);
+ else
+=09subst->seen =3D Fcons (subtree, subst->seen);
+ }
=20
/* Recurse according to subtree's type.
Every branch must return a Lisp_Object. */
@@ -5522,6 +5519,8 @@ init_lread (void)
Vload_true_file_name =3D Qnil;
Vstandard_input =3D Qt;
Vloads_in_progress =3D Qnil;
+
+ Funintern (Qplaceholder, Qnil);
}
=20
/* Print a warning that directory intended for use USE and with name
@@ -5931,4 +5930,5 @@ syms_of_lread (void)
DEFSYM (Qinternal_macroexpand_for_load,
=09 "internal-macroexpand-for-load");
DEFSYM (Qread_minibuffer, "read-minibuffer");
+ DEFSYM (Qplaceholder, "placeholder");
}
diff --git a/test/src/lread-tests.el b/test/src/lread-tests.el
index d1320a665a5..d1d040f2131 100644
--- a/test/src/lread-tests.el
+++ b/test/src/lread-tests.el
@@ -309,7 +309,8 @@ lread-circle
(dolist (str lread-test-circle-cases)
(ert-info (str :prefix "input: ")
(should (equal (lread-test-read-and-print str) str))))
- (should-error (read-from-string "#1=3D#1#") :type 'invalid-read-syntax))
+ (should-error (read-from-string "#1=3D#1#") :type 'invalid-read-syntax)
+ (should-error (read-from-string "#1=3D#2=3D#1#") :type 'invalid-read-syn=
tax))
=20
(ert-deftest lread-deeply-nested ()
;; Check that we can read a deeply nested data structure correctly.
--=20
2.51.1
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.Received: (at 79782) by debbugs.gnu.org; 8 Nov 2025 08:12:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 03:12:16 2025 Received: from localhost ([127.0.0.1]:50490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHe3T-0001RJ-TA for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:12:16 -0500 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:56723) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vHe3Q-0001RC-EZ for 79782 <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:12:13 -0500 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-47775fb6c56so1821365e9.1 for <79782 <at> debbugs.gnu.org>; Sat, 08 Nov 2025 00:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762589526; x=1763194326; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=6Wi1lDIREiJrPm9aQtCNGGadX9d8VfVLBDNcgFuFO5A=; b=m7ubFbHtOR2los0r0GKHl1mobafNVPFCuW4ojnu7aYgL8TaWxb1G/DyEemEQnQqKB0 sywt6klOa/t7f4hPYSoKsgNoxVyWj4hnH7XuT9oTZaBNvaDj0hNRSvhLduHg6b7KclhG dKjmdmvN6SA9jkiVsTt6fJy9HyryamnoXgX/Yol5vj18vouF3yWSYLCepjAZHdGd7OvA GVZR869jo42aTJW3uSBoRdzDo4mAG1dp+8TCAXCXcZlAZMEZHo1sViVO6oBcQ+wcbbfw cb4yw7vsUPfaox2yO+gi+9VU3lokdvYucJxC6Hwre6L2fYtoavULuFCxbVXnogv+/+/y jniA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762589526; x=1763194326; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6Wi1lDIREiJrPm9aQtCNGGadX9d8VfVLBDNcgFuFO5A=; b=fFtamFAou1tCUovIEFCE32kT4q/6OS/FiPJU40Z2/4HQL/PPCW4k7wAD++GO1yaNvj fW1oP1466Lle9GOvxNS1l4ctprp/4Qf3DwAjKn7raTapxE3gXIPpF7KKnIRRuAG1S6++ SzLdCDJ5b3LgFt5vcIXI+FA+bJxDMJfsHFz9QeuSIbdBkYdxZlOj9wxQjs1Z+IlY4K7o rgdKvABruGLQiTvyjgC9xbuQecAewVjNem/WuGVeeZevLR46+MHxJKik7C3fm/MeUJxg qr3qQ4XhjThwU+TzvnNmTUUW7Ho95VVxA+U4d4XKt/rVF3gw18PiUMeeRiIAIBhKvvOF Y5kA== X-Gm-Message-State: AOJu0Yy1gdrm3Z4I7SULb6dq4pk7WJBRa7LqC2MSQpATrumJuc+Xhi5c nnmTp+MQHRVOcDvXt+rb3idogkuVsERaobk3nbbZZnP57OVqVwscUi3k/+irR2U9 X-Gm-Gg: ASbGncuxwkkWTv9LFYS7A2SdNVcsrTs31cvJaQX81t2WejdX6DMI71FGOwMM9Cag+cj /GDgOrdzhMhgvsisXCM5zRDi0n6G4m/mADipWubTsOf+R8oUJWIy4pggVbnm3SJKXoNIg6X+nag W2pwUpL9xOmsCDHNmgGyPhfnhgxb5417J8StlisLGORGp07HCTnyeELfqr1yyerer1/NHgMV54W kTV30/BwaJwIRSMDS5UpnjfFuA8oBsXMr1A0rjufnhpV72kKDi/YFj/0cbBbW8dx9Jq8vIq2krA afZSYjSm4gnClXkBlD/id+/nqqkRTpLFV4k4A+z6ThDK+zagooJxU53fsF+HbKjhMljKpIM/FAo bKQKKsJQw3T0rXz3j6i/mLvGwQ45/OuH3q6naM9fIg/oRsNSAV8HE1zrYLGG7YCRh5n7NDnW1x5 IvbiVxbothbXtU0wdc15R/ftwP/GGt880lASGeSVGUSvKOMMgZSaRKYNfhdSsVzq7LSfrvDKrnB SWWsN2QAZQnBScy4mx73aw= X-Google-Smtp-Source: AGHT+IFiZvt9+kK9BxYXdTf1uGZ5Bllh9iHRuQpf07A849LPC//tqUg467XgmwMpJlEMAi5Wlnz51w== X-Received: by 2002:a05:600c:3ba8:b0:471:14b1:da13 with SMTP id 5b1f17b1804b1-4777323087fmr11833825e9.14.1762589525362; Sat, 08 Nov 2025 00:12:05 -0800 (PST) Received: from pro4 (p200300e0b7172900909ecbe2ac26ed0b.dip0.t-ipconnect.de. [2003:e0:b717:2900:909e:cbe2:ac26:ed0b]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4776bcdd833sm86842445e9.9.2025.11.08.00.12.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 08 Nov 2025 00:12:04 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete In-Reply-To: <m2frapobv5.fsf@HIDDEN> References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN> <m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN> <m2ms4xogu7.fsf@HIDDEN> <871pm91w33.fsf@HIDDEN> <m2frapobv5.fsf@HIDDEN> Date: Sat, 08 Nov 2025 09:12:00 +0100 Message-ID: <m27bw1ndtb.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) 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: 79782 Cc: 79782 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > Pip Cet <pipcet@HIDDEN> writes: > >>> Is it something the compilation process outputs? What the heck. I would >>> never have expected anything like that. Not even that it does the >>> compilation in another process. >> >> IIUC, the reason for the separate compilation process is that libgccjit >> has memory leaks or crashes in too many versions. Best to use a separate >> process for it. > > Yeah, I meanwhile found this: > > comp.el: > 3335 (defun comp--final (_) > 3336 "Final pass driving the C back-end for code emission." > 3337 (unless comp-dry-run > 3338 ;; Always run the C side of the compilation as a sub-process > 3339 ;; unless during bootstrap or async compilation (bug#45056). G= CC > 3340 ;; leaks memory but also interfere with the ability of Emacs to > 3341 ;; detect when a sub-process completes (TODO understand why). > 3342 (if (or comp-running-batch-compilation comp-async-compilation) > 3343 (comp--final1) > 3344 ;; Call comp--final1 in a child process. > > Didn't follow the expensive case in the following lines. > > The comment if from 2020-07. Maybe this is longer necessary? How knows. > Not so good for a library. > > >> >>> Anyway. Thanks, and I guess I should close this then. >> >> I'm not sure. Both the performance and the recursion depth of >> Flread__substitute_object_in_subtree seem worrying to me. > > Please re-open as you see fit. > >> >> Without a patch, without compilation, and on this somewhat outdated >> machine (likely much faster on Apple Silicon), I get: >> >> $ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lis= p-native-compile)' >> >> real 9m58.466s >> user 9m56.942s >> sys 0m0.663s >> >> With some spur-of-the-moment patching, I get: >> >> $ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lis= p-native-compile)' >> >> real 0m49.738s >> user 0m49.172s >> sys 0m0.488s >> >> Assuming this isn't an -felide-function-bodies >> (https://gcc.gnu.org/pipermail/gcc/2017-April/223035.html) style >> optimization, we should probably do something like it, with a heuristic >> for when to switch to the "seen" hash table. > > Makes a lot of sense to me. > > I guess someone should also check what's up with libgccjit, but that's > another independent story. BTW, only related because I stumbled over this "hang" while doing this: Another old todo item of mine was to find out what percentage of time is spent in which native native compiler pass. The result of an AOT build of cl-packages is, producing a CSV file in comp.el from the timings, and throwing that into Gemini: | Compiler Pass | Total Runtime (%) | Percent | |-----------------+-------------------+----------| | comp--final | 1220.6278 | 43.5291 | | comp--fwprop | 958.5292 | 34.1823 | | comp--spill-lap | 586.5226 | 20.9161 | | comp--add-cstrs | 12.0164 | 0.4285 | | comp--limplify | 11.9511 | 0.4262 | | ... | ... | ... | | TOTAL | 2804.1677 | 100.0000 | comp--final is basically libgccjit. Just in case it's interesting, dunno.
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 19:56:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 14:56:42 2025 Received: from localhost ([127.0.0.1]:48047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHSZd-0006TH-Hx for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 14:56:42 -0500 Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631]:52390) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vHSZb-0006Sy-Ew for 79782 <at> debbugs.gnu.org; Fri, 07 Nov 2025 14:56:40 -0500 Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-b72134a5125so180328466b.0 for <79782 <at> debbugs.gnu.org>; Fri, 07 Nov 2025 11:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762545392; x=1763150192; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=711k4fwTBsdisCcvLOnvYpvSVqjNILZWakTEX6cVWC0=; b=GK2mX6dTWxuvIcLU9zXab+Qxr11pBuA277giNTtzfbQNjA6SufA3Sfq7VP1j33NKAG FmzKiYhk0klpdP0NSbducufgvlblE6Kl2QWd/1eWsg4diGIE0uCtof/oLvB9jYnROlLX 4gN9onZJLFnaGmQstlw5EuvWiufndaJiqLQwos7QPZ+WXsIBSw8fGlMGtxmbjtNCNLSQ rFgTxLgB4tgCiTVecNrtD6xnZerjprTIuca8SVDxVkZk1iv1H0sTEJq9WAfyGeb7RyGM o08hfkdBpuNqDQu5IIvCcYz0olHvxLeVLd95XQ/pQ1V3IEFBxzwHHmwOZNkDCCEferkv y+GA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762545392; x=1763150192; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=711k4fwTBsdisCcvLOnvYpvSVqjNILZWakTEX6cVWC0=; b=Uzx3wcuHQrzj0lfUqJg5qRSlynnDAyyx75gPzV/797oZoex/CQOtuEsI/tt1YVO+lD TpvMK5AD/DZXuZWQab4bSYAnFA0Ikv+NpfLWqWD5cKOaQYQhFTdeuOUMS9vWsf4JeUiW X5YLv8yTf+rKJQsyz2hUNJEEtm0di/nM1XOLcQDGYXgxm3dsGMNZAnICgKBv9/uS2VF3 p/KFCk3t5u3GkGDb4XSbr0RHZFdMcpVZMRtAPRUbwnsCyMylPTw4zG1rLSzndZefAgQv 6bpz6VTlzFfX3WUGV6Nutw3DMNBWNepBMXbJUg7z3UO18FyDCOLI0lIs3i7YL7+d3XSh fZyw== X-Gm-Message-State: AOJu0YyzJRocPdZ6AwbruSg8tvV+KRaetcxhxoHMw9YL+q0wtgeHeY22 uj26biERaj/FL/b/avXcII8hc2cRLZuBUFy2ui4A9H8zZkgVpfW63ScMO6jiKbDj X-Gm-Gg: ASbGnctdfujlP6fF1Nz2Yzi8ekBn/uO5fPYvia6VcQuHpAgqwCtbg5Kdsy/QHZ8SmQ/ qLOXjVoXA/YegHIfOt+72CLUmBE1fmWLt82/CRWkgmnF+Axo/ggvDETn6lG4N1+FhnP0o/yJeZ9 Fl+YkCJo3TnPiO4EcydkRq/H9doJ4eA1REIOm/U2e8Lv6BbYk9RY2/n14NUu7cLG11+Tw7Lav/r CprM70jh7H3d1tYoFCqOc9yiCFIaxgHDjihuwpJGB93LKcbQlq5qZJqH3EWqTgBMGezwTLhUcqB LdMcbM8y3Oz0cKWx42LEigO/pJeHhNmDLX9bcdlUoiHiLWkhUPuKNni/dcO0IR3RXS1sbHuXjcN y2EHcvmSmiVrb+srWoPSAm9guoPhDoKkuwkBNvtcdWA3oW17zBf8gZco0FaQff5nby29T7HltuA AN6j7tJQvxmI9uVGA4S+Bjd0TeyVfszN/gV5Cbydb0wQJGS3h2jxgD0gKMXgoFaj4ld5Ibnirvk NWQZMaCxvSQ X-Google-Smtp-Source: AGHT+IHIA/CzbQLb0dPGfchBXCGPSwcFg8bNRE1bTtoUHGkhm3opyx16dte4d5XbnLhfQYdr9NzQcw== X-Received: by 2002:a17:907:da3:b0:b72:b389:b799 with SMTP id a640c23a62f3a-b72e03617ffmr43744566b.23.1762545392231; Fri, 07 Nov 2025 11:56:32 -0800 (PST) Received: from pro4 (p200300e0b7103700b9dd3d7a9e7f9444.dip0.t-ipconnect.de. [2003:e0:b710:3700:b9dd:3d7a:9e7f:9444]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b72bfa24d1fsm318372166b.73.2025.11.07.11.56.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Nov 2025 11:56:31 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete In-Reply-To: <871pm91w33.fsf@HIDDEN> References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN> <m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN> <m2ms4xogu7.fsf@HIDDEN> <871pm91w33.fsf@HIDDEN> Date: Fri, 07 Nov 2025 20:56:30 +0100 Message-ID: <m2frapobv5.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79782 Cc: 79782 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Pip Cet <pipcet@HIDDEN> writes: >> Is it something the compilation process outputs? What the heck. I would >> never have expected anything like that. Not even that it does the >> compilation in another process. > > IIUC, the reason for the separate compilation process is that libgccjit > has memory leaks or crashes in too many versions. Best to use a separate > process for it. Yeah, I meanwhile found this: comp.el: 3335 (defun comp--final (_) 3336 "Final pass driving the C back-end for code emission." 3337 (unless comp-dry-run 3338 ;; Always run the C side of the compilation as a sub-process 3339 ;; unless during bootstrap or async compilation (bug#45056). GCC 3340 ;; leaks memory but also interfere with the ability of Emacs to 3341 ;; detect when a sub-process completes (TODO understand why). 3342 (if (or comp-running-batch-compilation comp-async-compilation) 3343 (comp--final1) 3344 ;; Call comp--final1 in a child process. Didn't follow the expensive case in the following lines. The comment if from 2020-07. Maybe this is longer necessary? How knows. Not so good for a library. > >> Anyway. Thanks, and I guess I should close this then. > > I'm not sure. Both the performance and the recursion depth of > Flread__substitute_object_in_subtree seem worrying to me. Please re-open as you see fit. > > Without a patch, without compilation, and on this somewhat outdated > machine (likely much faster on Apple Silicon), I get: > > $ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lisp-native-compile)' > > real 9m58.466s > user 9m56.942s > sys 0m0.663s > > With some spur-of-the-moment patching, I get: > > $ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lisp-native-compile)' > > real 0m49.738s > user 0m49.172s > sys 0m0.488s > > Assuming this isn't an -felide-function-bodies > (https://gcc.gnu.org/pipermail/gcc/2017-April/223035.html) style > optimization, we should probably do something like it, with a heuristic > for when to switch to the "seen" hash table. Makes a lot of sense to me. I guess someone should also check what's up with libgccjit, but that's another independent story.
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.
Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 19:28:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 14:28:37 2025
Received: from localhost ([127.0.0.1]:47871 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHS8S-0005AE-Lb
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 14:28:37 -0500
Received: from mail-24418.protonmail.ch ([109.224.244.18]:33821)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHS8O-0005A8-AB
for 79782 <at> debbugs.gnu.org; Fri, 07 Nov 2025 14:28:34 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762543704; x=1762802904;
bh=zAUVk12p8yoOuvdHP8Un0yq85Eemg9wrbgtKlmOunHA=;
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;
b=iBEINAwpNIPk+e1LhDtHwvlMiYZ7O87HrU1Wh7ewjKqEx4VrmmnRcZjr5Tsxq1aut
GVlsQfs7A9ApHQTUHtHaZwwesA/v8QKYHywD7ITVH98orLuYm/IHnDZWC5g0uz6mG3
++b5nGUqiqOkF6YneUC9I0+GKKT+Hn4tzbOgxShWPC206spUDg70aBYmsOQwc9aMUp
hGy5CwDCttwcdEJdDmU4v+XHGdIfFpPwHnnTsWNfGaOsl/J74jRs8w6jIqi4U5kQf0
qR8+a8Yr8gBYOfj6mag1s36IkHkt4o4wjqIDUZZnF9ciQWNe3g8LAhECaG236mE9re
sX9rDoBKbvNvQ==
Date: Fri, 07 Nov 2025 19:28:21 +0000
To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79782: 31.0.50;
M-x emacs-lisp-native-compile does not complete
Message-ID: <871pm91w33.fsf@HIDDEN>
In-Reply-To: <m2ms4xogu7.fsf@HIDDEN>
References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN>
<m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN>
<m2ms4xogu7.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 8b834f3f57ddfbbc3d45ac6a9b659fca6b079c66
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: 79782
Cc: 79782 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Pip Cet <pipcet@HIDDEN> writes:
>
>> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>>
>>> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>>>
>>>> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>>>>
>>>>> To reproduce, in an Emacs build with native compilation
>>>>>
>>>>> - emacs -Q
>>>>> - C-x C-f <repo>/lisp/emacs-lisp/comp.el RET
>>>>> - M-x emacs-lisp-native-compile RET
>>>>>
>>>>> The command does not complete. If one evaluates the buffer first, the=
n
>>>>> M-x toggle-debug-on-quit, and C-g, one can see that it is stuck
>>>>> somewhere in the native compiler.
>>>>>
>>>>> In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin25.1.0, NS
>>>>> appkit-2685.20 Version 26.1 (Build 25B78)) of 2025-11-07 built on pr=
o4
>>>>> Repository revision: be527b570465dad453f5aebba3c552f14ec98e2b
>>>>> Repository branch: master
>>>>> System Description: macOS 26.1
>>>>>
>>>>> Configured using:
>>>>> 'configure --with-native-compilation --with-ns CC=3Dclang
>>>>> 'CFLAGS=3D-Wgnu-imaginary-constant -Wunused-result -g
>>>>> -Wno-ignored-attributes -Wno-flag-enum -Wno-missing-method-return-ty=
pe
>>>>> -Wno-variadic-macros -Wno-strict-prototypes -Wno-availability
>>>>> -Wno-nullability-completeness -g -O2' --cache-file
>>>>> /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.maste=
r'
>>>>
>>>> I went 3 years back for bisecting, but could not find a working good
>>>> commit, sorry.
>>>
>>> Many samples taken with macOS' Activity Monitor like this:
>>>
>>> Call graph:
>>> 867 Thread_4055222 DispatchQueue_1: com.apple.main-thread (seria=
l)
>>> 867 start (in dyld) + 7184 [0x19e161d54]
>>> 867 main (in emacs) + 8008 [0x104db18c0] emacs.c:2629
>>> 867 Frecursive_edit (in emacs) + 368 [0x104db2a70] keyboar=
d.c:832
>>> 867 recursive_edit_1 (in emacs) + 164 [0x104db2718] keyb=
oard.c:749
>>> 867 command_loop (in emacs) + 268 [0x104db28c8] keyboa=
rd.c:1141
>>> 867 internal_catch (in emacs) + 256 [0x104e3a788] ev=
al.c:1370
>>> 867 command_loop_2 (in emacs) + 52 [0x104db30b0] k=
eyboard.c:1163
>>> 867 internal_condition_case (in emacs) + 260 [0x1=
04e3b1c8] eval.c:1690
>>> 867 command_loop_1 (in emacs) + 828 [0x104db340=
0] keyboard.c:1424
>>> 867 read_key_sequence (in emacs) + 1380 [0x10=
4db4de0] keyboard.c:11146
>>> 867 read_char (in emacs) + 6340 [0x104db81a=
8] keyboard.c:3020
>>> 867 wait_reading_process_output (in emacs)=
+ 4200 [0x104e9a200] process.c:5810
>>> 867 thread_select (in emacs) + 84 [0x10=
4ebd624] thread.c:659
>>> 867 really_call_select (in emacs) + 88=
[0x104ebd6b0] thread.c:624
>>> 867 pselect$DARWIN_EXTSN (in libsyst=
em_kernel.dylib) + 64 [0x19e4ecf94]
>>> 867 __pselect (in libsystem_kernel=
.dylib) + 8 [0x19e4ed0bc]
>>
>> That's the main process; the idea is that there will be a child process
>> which does the actual compilation.
>>
>> How long did you wait? Over here, after some phenomenally deep recursion
>> in Flread__substitute_object_in_subtree, the compilation appears to make
>> (very, very slow) progress.
>>
> How weird. I hadn't seen a second process pop up in Activity Monitor.
> Now repeating that and waiting for say 10 minutes and the parent process
> is responsive again.
>
>> The problem is we're reading a very large very circular object and the
>> reader isn't really prepared for that. It's about 13 MB and involves
>> about 100000 #N# substitutions.
>
> Is it something the compilation process outputs? What the heck. I would
> never have expected anything like that. Not even that it does the
> compilation in another process.
IIUC, the reason for the separate compilation process is that libgccjit
has memory leaks or crashes in too many versions. Best to use a separate
process for it.
> Anyway. Thanks, and I guess I should close this then.
I'm not sure. Both the performance and the recursion depth of
Flread__substitute_object_in_subtree seem worrying to me.
Without a patch, without compilation, and on this somewhat outdated
machine (likely much faster on Apple Silicon), I get:
$ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lisp-n=
ative-compile)'
real 9m58.466s
user 9m56.942s
sys 0m0.663s
With some spur-of-the-moment patching, I get:
$ time ./src/emacs -Q --batch lisp/emacs-lisp/comp.el --eval '(emacs-lisp-n=
ative-compile)'
real 0m49.738s
user 0m49.172s
sys 0m0.488s
Assuming this isn't an -felide-function-bodies
(https://gcc.gnu.org/pipermail/gcc/2017-April/223035.html) style
optimization, we should probably do something like it, with a heuristic
for when to switch to the "seen" hash table.
From 57b347cd378c3c4ecc1008396f952e0ea10ce515 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 7 Nov 2025 19:22:48 +0000
Subject: [PATCH 1/2] Faster substitution of #N# objects in the reader
(bug#79782)
This reduces recursion depth, which is part of the problem.
* src/lread.c (substitute_object_recurse): Avoid recursion for the CDR
of cons cells.
---
src/lread.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/src/lread.c b/src/lread.c
index 9c4da863363..6fe800c6f29 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4405,16 +4405,19 @@ substitute_object_recurse (struct subst *subst, Lis=
p_Object subtree)
if (EQ (subst->placeholder, subtree))
return subst->object;
=20
+ Lisp_Object orig_subtree =3D subtree;
+
+ again:
/* For common object types that can't contain other objects, don't
bother looking them up; we're done. */
if (SYMBOLP (subtree)
|| (STRINGP (subtree) && !string_intervals (subtree))
|| NUMBERP (subtree))
- return subtree;
+ return orig_subtree;
=20
/* If we've been to this node before, don't explore it again. */
if (!NILP (Fmemq (subtree, subst->seen)))
- return subtree;
+ return orig_subtree;
=20
/* If this node can be the entry point to a cycle, remember that
we've seen it. It can only be such an entry point if it was made
@@ -4432,7 +4435,7 @@ substitute_object_recurse (struct subst *subst, Lisp_=
Object subtree)
{
=09ptrdiff_t i =3D 0, length =3D 0;
=09if (BOOL_VECTOR_P (subtree))
-=09 return subtree;=09=09/* No sub-objects anyway. */
+=09 return orig_subtree;=09=09/* No sub-objects anyway. */
=09else if (CHAR_TABLE_P (subtree) || SUB_CHAR_TABLE_P (subtree)
=09=09 || CLOSUREP (subtree) || HASH_TABLE_P (subtree)
=09=09 || RECORDP (subtree))
@@ -4451,13 +4454,13 @@ substitute_object_recurse (struct subst *subst, Lis=
p_Object subtree)
=09for ( ; i < length; i++)
=09 ASET (subtree, i,
=09=09substitute_object_recurse (subst, AREF (subtree, i)));
-=09return subtree;
+=09return orig_subtree;
}
=20
case Lisp_Cons:
XSETCAR (subtree, substitute_object_recurse (subst, XCAR (subtree)))=
;
- XSETCDR (subtree, substitute_object_recurse (subst, XCDR (subtree)))=
;
- return subtree;
+ subtree =3D XCDR (subtree);
+ goto again;
=20
case Lisp_String:
{
@@ -4467,12 +4470,12 @@ substitute_object_recurse (struct subst *subst, Lis=
p_Object subtree)
=09INTERVAL root_interval =3D string_intervals (subtree);
=09traverse_intervals_noorder (root_interval,
=09=09=09=09 substitute_in_interval, subst);
-=09return subtree;
+=09return orig_subtree;
}
=20
/* Other types don't recurse any further. */
default:
- return subtree;
+ return orig_subtree;
}
}
=20
--=20
2.51.1
From d45977052af80e2434dde7b3185d2ff98ea4582d Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Fri, 7 Nov 2025 19:23:41 +0000
Subject: [PATCH 2/2] Faster substitution of #N# objects in the reader
(bug#79782)
This uses a hash table for the 'seen' tab.
* src/lread.c (Flread__substitute_object_in_subtree): Initialize
'subst.seen' with hash table.
(substitute_object_recurse): Use a hash table to remember seen
objects.
---
src/lread.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/lread.c b/src/lread.c
index 6fe800c6f29..8525e814a4a 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -4388,7 +4388,7 @@ DEFUN ("lread--substitute-object-in-subtree",
if any object might be circular. */)
(Lisp_Object object, Lisp_Object placeholder, Lisp_Object completed)
{
- struct subst subst =3D { object, placeholder, completed, Qnil };
+ struct subst subst =3D { object, placeholder, completed, CALLN (Fmake_ha=
sh_table, QCtest, Qeq) };
Lisp_Object check_object =3D substitute_object_recurse (&subst, object);
=20
/* The returned object here is expected to always eq the
@@ -4416,7 +4416,7 @@ substitute_object_recurse (struct subst *subst, Lisp_=
Object subtree)
return orig_subtree;
=20
/* If we've been to this node before, don't explore it again. */
- if (!NILP (Fmemq (subtree, subst->seen)))
+ if (!NILP (Fgethash (subtree, subst->seen, Qnil)))
return orig_subtree;
=20
/* If this node can be the entry point to a cycle, remember that
@@ -4425,7 +4425,7 @@ substitute_object_recurse (struct subst *subst, Lisp_=
Object subtree)
COMPLETED. */
if (EQ (subst->completed, Qt)
|| hash_find (XHASH_TABLE (subst->completed), subtree) >=3D 0)
- subst->seen =3D Fcons (subtree, subst->seen);
+ Fputhash (subtree, Qt, subst->seen);
=20
/* Recurse according to subtree's type.
Every branch must return a Lisp_Object. */
--=20
2.51.1
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.Gerd Möllmann <gerd.moellmann@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 18:09:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 13:09:16 2025 Received: from localhost ([127.0.0.1]:47430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHQtf-0007sr-HC for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 13:09:16 -0500 Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:58635) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vHQtd-0007sj-4f for 79782 <at> debbugs.gnu.org; Fri, 07 Nov 2025 13:09:14 -0500 Received: by mail-wm1-x32b.google.com with SMTP id 5b1f17b1804b1-4775638d819so6157765e9.1 for <79782 <at> debbugs.gnu.org>; Fri, 07 Nov 2025 10:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762538946; x=1763143746; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bJhhyHhMYUXK/9lKFatqLkoJyUpghh9x9T1BRj1sD2w=; b=E2XaOOQk3Jg3XBeulrKFP3bmJb10iJVHqJGfvoEV5i/0val7Rdg++6DEkXzPk+G1u0 vJarAcYm2hU+kxRvU4gwyRWNTAhz4HsHYrMDLcAYcNgHKTgsBSMdNLMtChFS0ektRWy6 HPJtKnSIbpZAGVjfPZnXk9OQA6OPGmJll1poNt4b7NgxMkanNHVEv6N5ZiQqbXbYzDjG eTfWaFPPfHWTVEcaykorE0OQquAM/nortclVc1Xd52tGzLRMqMofgqs5aI6ch+Z62a09 CcphvAbaHfkL2vosFb4tegKcbq4uchr42tLKmbUB9/LWC5ZRrgjHAQ3GiJjj/VBtmwcP CEZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762538946; x=1763143746; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=bJhhyHhMYUXK/9lKFatqLkoJyUpghh9x9T1BRj1sD2w=; b=Sp9D4myILht5ijMXowxsXa937bVnHlDSegveyNa3mvh4W5ZewN2o9C6T72y2jF3lCI X4plOx2Tl2F6zGH4tPFzauc1T0oyrpufe4x8ofA93cQ90sofwPkykEDzbgRe64hNB4LY 82fO1QZkSNMAFjPiicm0cofqQsXuB6q1a/YEgIvflUnuPSum2pogkQ5xpM0juJx4rXmX Z26b/CMGOAHVOzaRVZMyNoP8hpFbVPG/NLJpSnIjcy7Fky+6iuLjPH9tf8fVbi6Af6hT dsMkN9VhJwWCjPcBe4qYJILS75j7Z6kUI/Ybs3AcuYVF8WBu5PBg0Sac5vcM9iprI4Ys /CoA== X-Gm-Message-State: AOJu0YzICerBFSim2CNQeXHBB6PhMYQYWsjDgqZQj+aKuHfoghX0lDZy GsrFRX+CGYOR3pZ8l8xwjDnjrbU2ZURzMdZLjgn+R8bOA4FbdHujtjpgucZvMeeF X-Gm-Gg: ASbGncv2Vz9oMLAMRfi9cLBjJkvUDklpulun+OGhnKm9fAl2anmzgeGZ9cj5UpBSmt2 UD9qo6KZfkkjq2KuPTus8Y6No6wzLYtrJgnAhAUS6zfrwEbioaHG8LO4kzjgOSpcmGQjpvFfEpV LubwQUFnYVS2ZWDfY+5uoeucrP4jY6oYkSY8yDj1AuEQlS2wEy6WCBwHlYoB3HKcSLlQzB8Omhc 9ejiN3WNOaDolUnqrMVzsevxLfBONc3vrxLU1EqiMMApk8PdxKhtCn+rskKEzGPGJcKAhQKWoZf 9LA8HUJPBRBa2nWENP0tEFv//UY3B6VAplE21NmiFD7UMIEK7cqwBOH5927hvPDHMtvClPY92Y+ hZzaX+6WJv0mmjacZx1IlrATfROCrmiqg6xlljOZTO/hs2SglDtZfu1UCAbJwo3AZvwloWHN4Qg dHkAjGARo6pqcfZvCtyHxZ7aD5g6lYNJXWi2EKdtvbla4yUcFuyZ9g1HfYJduMY9XcssnM/4dp+ AXIBI4jmZsT X-Google-Smtp-Source: AGHT+IFkw4Mu3PJKsGAph0avdy2QovlVlhVsVSWcR0FY4tE7bKhHHg2ZjcwX0TjvtFQyQwyv6u+vjg== X-Received: by 2002:a05:600c:4695:b0:477:54cd:202f with SMTP id 5b1f17b1804b1-4776bc86533mr33371745e9.3.1762538946346; Fri, 07 Nov 2025 10:09:06 -0800 (PST) Received: from pro4 (p200300e0b7103700b9dd3d7a9e7f9444.dip0.t-ipconnect.de. [2003:e0:b710:3700:b9dd:3d7a:9e7f:9444]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47761c2fe2asm121678455e9.5.2025.11.07.10.09.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Nov 2025 10:09:05 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete In-Reply-To: <87ikfl216m.fsf@HIDDEN> References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN> <m2tsz5on4x.fsf@HIDDEN> <87ikfl216m.fsf@HIDDEN> Date: Fri, 07 Nov 2025 19:09:04 +0100 Message-ID: <m2ms4xogu7.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) 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: 79782 Cc: 79782 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Pip Cet <pipcet@HIDDEN> writes: > Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > >> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >> >>> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >>> >>>> To reproduce, in an Emacs build with native compilation >>>> >>>> - emacs -Q >>>> - C-x C-f <repo>/lisp/emacs-lisp/comp.el RET >>>> - M-x emacs-lisp-native-compile RET >>>> >>>> The command does not complete. If one evaluates the buffer first, then >>>> M-x toggle-debug-on-quit, and C-g, one can see that it is stuck >>>> somewhere in the native compiler. >>>> >>>> In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin25.1.0, NS >>>> appkit-2685.20 Version 26.1 (Build 25B78)) of 2025-11-07 built on pro4 >>>> Repository revision: be527b570465dad453f5aebba3c552f14ec98e2b >>>> Repository branch: master >>>> System Description: macOS 26.1 >>>> >>>> Configured using: >>>> 'configure --with-native-compilation --with-ns CC=3Dclang >>>> 'CFLAGS=3D-Wgnu-imaginary-constant -Wunused-result -g >>>> -Wno-ignored-attributes -Wno-flag-enum -Wno-missing-method-return-type >>>> -Wno-variadic-macros -Wno-strict-prototypes -Wno-availability >>>> -Wno-nullability-completeness -g -O2' --cache-file >>>> /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.master' >>> >>> I went 3 years back for bisecting, but could not find a working good >>> commit, sorry. >> >> Many samples taken with macOS' Activity Monitor like this: >> >> Call graph: >> 867 Thread_4055222 DispatchQueue_1: com.apple.main-thread (serial) >> 867 start (in dyld) + 7184 [0x19e161d54] >> 867 main (in emacs) + 8008 [0x104db18c0] emacs.c:2629 >> 867 Frecursive_edit (in emacs) + 368 [0x104db2a70] keyboard= .c:832 >> 867 recursive_edit_1 (in emacs) + 164 [0x104db2718] keybo= ard.c:749 >> 867 command_loop (in emacs) + 268 [0x104db28c8] keyboar= d.c:1141 >> 867 internal_catch (in emacs) + 256 [0x104e3a788] eva= l.c:1370 >> 867 command_loop_2 (in emacs) + 52 [0x104db30b0] ke= yboard.c:1163 >> 867 internal_condition_case (in emacs) + 260 [0x10= 4e3b1c8] eval.c:1690 >> 867 command_loop_1 (in emacs) + 828 [0x104db3400= ] keyboard.c:1424 >> 867 read_key_sequence (in emacs) + 1380 [0x104= db4de0] keyboard.c:11146 >> 867 read_char (in emacs) + 6340 [0x104db81a8= ] keyboard.c:3020 >> 867 wait_reading_process_output (in emacs) = + 4200 [0x104e9a200] process.c:5810 >> 867 thread_select (in emacs) + 84 [0x104= ebd624] thread.c:659 >> 867 really_call_select (in emacs) + 88 = [0x104ebd6b0] thread.c:624 >> 867 pselect$DARWIN_EXTSN (in libsyste= m_kernel.dylib) + 64 [0x19e4ecf94] >> 867 __pselect (in libsystem_kernel.= dylib) + 8 [0x19e4ed0bc] > > That's the main process; the idea is that there will be a child process > which does the actual compilation. > > How long did you wait? Over here, after some phenomenally deep recursion > in Flread__substitute_object_in_subtree, the compilation appears to make > (very, very slow) progress. > How weird. I hadn't seen a second process pop up in Activity Monitor. Now repeating that and waiting for say 10 minutes and the parent process is responsive again. > The problem is we're reading a very large very circular object and the > reader isn't really prepared for that. It's about 13 MB and involves > about 100000 #N# substitutions. Is it something the compilation process outputs? What the heck. I would never have expected anything like that. Not even that it does the compilation in another process. Anyway. Thanks, and I guess I should close this then.
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 17:38:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 12:38:27 2025 Received: from localhost ([127.0.0.1]:47271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHQPr-0006pr-Gh for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 12:38:27 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:56639) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHQPp-0006pS-2w for 79782 <at> debbugs.gnu.org; Fri, 07 Nov 2025 12:38:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762537097; x=1762796297; bh=44f7vrm9vPG8a/IBVroiO47HZJZXJGgdIrX8dKx7OSI=; 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; b=PdkhaYHIl0Gx2J/YpRq5bOVaHKON3NYe4X+CCqgvV22iL86NORRzlLIPsp8kMy/iP dDXtkoZ69dTZi5/9yMZQw4lqALFpc8NTYeHvj3scxgKQXtZgYd9FYgdVejGbaTcTVr bECVDq+M3ZSHta3Ug5cbVps6ruVNqYXUFCRUUkeazVmFyExh6OMIXqfl6qxX3fCSy8 2N9WSoN9hFn2p4afPNjAQ4Ml13wgnAoqLV/WybY302Q4Cd4ypw1ydizxxafUm7aORX 74gD/emrnEu9rcNIM/EMijK1E9t6d6MaiMv7zwEYden8liI24u9DJh6eti4aAFwI8c b7gu8BdlQE91A== Date: Fri, 07 Nov 2025 17:38:14 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete Message-ID: <87ikfl216m.fsf@HIDDEN> In-Reply-To: <m2tsz5on4x.fsf@HIDDEN> References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN> <m2tsz5on4x.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 5d9bcbe4ffaa39de5c28024d6c5a6647173acc81 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: 79782 Cc: 79782 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > >> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >> >>> To reproduce, in an Emacs build with native compilation >>> >>> - emacs -Q >>> - C-x C-f <repo>/lisp/emacs-lisp/comp.el RET >>> - M-x emacs-lisp-native-compile RET >>> >>> The command does not complete. If one evaluates the buffer first, then >>> M-x toggle-debug-on-quit, and C-g, one can see that it is stuck >>> somewhere in the native compiler. >>> >>> In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin25.1.0, NS >>> appkit-2685.20 Version 26.1 (Build 25B78)) of 2025-11-07 built on pro4 >>> Repository revision: be527b570465dad453f5aebba3c552f14ec98e2b >>> Repository branch: master >>> System Description: macOS 26.1 >>> >>> Configured using: >>> 'configure --with-native-compilation --with-ns CC=3Dclang >>> 'CFLAGS=3D-Wgnu-imaginary-constant -Wunused-result -g >>> -Wno-ignored-attributes -Wno-flag-enum -Wno-missing-method-return-type >>> -Wno-variadic-macros -Wno-strict-prototypes -Wno-availability >>> -Wno-nullability-completeness -g -O2' --cache-file >>> /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.master' >> >> I went 3 years back for bisecting, but could not find a working good >> commit, sorry. > > Many samples taken with macOS' Activity Monitor like this: > > Call graph: > 867 Thread_4055222 DispatchQueue_1: com.apple.main-thread (serial) > 867 start (in dyld) + 7184 [0x19e161d54] > 867 main (in emacs) + 8008 [0x104db18c0] emacs.c:2629 > 867 Frecursive_edit (in emacs) + 368 [0x104db2a70] keyboard.= c:832 > 867 recursive_edit_1 (in emacs) + 164 [0x104db2718] keyboa= rd.c:749 > 867 command_loop (in emacs) + 268 [0x104db28c8] keyboard= .c:1141 > 867 internal_catch (in emacs) + 256 [0x104e3a788] eval= .c:1370 > 867 command_loop_2 (in emacs) + 52 [0x104db30b0] key= board.c:1163 > 867 internal_condition_case (in emacs) + 260 [0x104= e3b1c8] eval.c:1690 > 867 command_loop_1 (in emacs) + 828 [0x104db3400]= keyboard.c:1424 > 867 read_key_sequence (in emacs) + 1380 [0x104d= b4de0] keyboard.c:11146 > 867 read_char (in emacs) + 6340 [0x104db81a8]= keyboard.c:3020 > 867 wait_reading_process_output (in emacs) += 4200 [0x104e9a200] process.c:5810 > 867 thread_select (in emacs) + 84 [0x104e= bd624] thread.c:659 > 867 really_call_select (in emacs) + 88 = [0x104ebd6b0] thread.c:624 > 867 pselect$DARWIN_EXTSN (in libsystem= _kernel.dylib) + 64 [0x19e4ecf94] > 867 __pselect (in libsystem_kernel.d= ylib) + 8 [0x19e4ed0bc] That's the main process; the idea is that there will be a child process which does the actual compilation. How long did you wait? Over here, after some phenomenally deep recursion in Flread__substitute_object_in_subtree, the compilation appears to make (very, very slow) progress. The problem is we're reading a very large very circular object and the reader isn't really prepared for that. It's about 13 MB and involves about 100000 #N# substitutions. Please give this at least an hour so we know whether it's just very slow or actually doesn't work at all. Pip
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.
Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 15:53:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:53:17 2025
Received: from localhost ([127.0.0.1]:46514 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHOm4-0005It-IT
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:53:17 -0500
Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:57424)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1vHOm1-0005Ik-Gl
for 79782 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:53:14 -0500
Received: by mail-wm1-x32f.google.com with SMTP id
5b1f17b1804b1-47754e9cc7fso6179975e9.2
for <79782 <at> debbugs.gnu.org>; Fri, 07 Nov 2025 07:53:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1762530787; x=1763135587; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=w1TUtNJCFGLMvqMWIqMbhy1rT2b4ZsbxkivnK4bEqXQ=;
b=D8pJJSC2KLIkh3Kb5k2IIPHQqUdcFzCn0ZbuI1yhuObYIOUwTYh0NFA/O4/QeZRHbp
9hDmEnjtKu0EJDZzk/oNu4jkNvVe0uIYFOfutrtOa/HJ+M1TuKjp/tr9oSowx4dl/rnV
bch0RiJj5KL5K5sKYKS3OnqzJXnCLrpPpkM7xh6JbABwl7KK2N9fH5DpgxjoR3PA/QOG
9xoOIaGcZaBYGcI1+mmKuclb7d4O319NB6uEYiTtBgoo98/LqlueVRjOr+635UCLn/UH
ukPicBV0EQSla0VoBX/W52KvTNEZHzQJMUqcirXIrLzadSuwSY90fjkAeBg5KA8ggNhv
AdTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1762530787; x=1763135587;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:to:from:x-gm-gg:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=w1TUtNJCFGLMvqMWIqMbhy1rT2b4ZsbxkivnK4bEqXQ=;
b=i5rSAj7akKkxsbmsE9NCacW63DP3qCyR4CKZGj+xfVgmEDNzCLg94SwKyT5z+kQ1Hd
nLlZTwaLvZiTBjWj4HJTAyTak9lptG6i/ro5rZ9jZWQUIhWT+Hj/l5x4IDf2dvZub7PY
XMjzeKLZTxO8rgUSuQkXFWkEW6xC1H4sE4nR/0LAe8YcTmPpShVuuyoaOOIucTbI2Ob3
hYkoRGFm2t/uDHNKY4Xvy7n0abxYfZI2s3iBbAgKm02xLvYE8P++wjzRWwihsdDs6GqC
xDd9b9dGh45bm/H40PqqdjixOcWIJ0tZ8rqPs8OaGsC7OTlsuLj1lDQfwiFqvyJqAdft
79gg==
X-Gm-Message-State: AOJu0Yz5joCrjmoGiXmFapLVKnWlq5ShUiwRwPvo5gjLjSedjm15StVr
Z+YYHEu1dT8SPdImUH/IodE0V7s4Wg99R2xI9oLcCTJA6Y250yXy6Hzmki9UxEe+
X-Gm-Gg: ASbGncs+XYrvT1qN3wxBZJ/uTiJS4cZK+PMYI0OuDPtvOkMo1DbfU4zigcrW4hll/VX
bbJT2S/MA/KnCxanGr1iTWd3eoRvJakZGUqXzJnXg4Oi4k6nv18On5AL3xCE2oq1QZs5n6ollia
jbr9S3AKbHRqXK1rNsL91P81yaKPUfZvvSOT+toTpx13YzLxotDu0Y85BshaDQLQwZ84Giusad4
z1gUa+UqLAmsmSPowDba5q4UxWA/FiMyOxwUzKS9RhKvjTzbYZeE32To2C17SY5wa82Op7NAWOz
MkkUfIntmAbUJU5exki+m342XbKKbkYVv+BlTWB+QDteoJs25h1SLYaRwDmpwuOM/Bry0g0dVRX
v/+PI/4I9R8lY8h53hKRcWTFtBXFC+rN5n34kl0cTArEtXiIB9tL73dMONMwf3kHzyRu35jhP7m
6zUnarRMSwlPJZNxmJOwk9JHO6RWnOxk4MkCVvfDSgGwIRoi2LsWg3Se32a74jOU6Xu9Ws6cWnf
QcgZ33klti05N7rlyfrW+o=
X-Google-Smtp-Source: AGHT+IGlFslsTwI0oXpLgtdN6/aidDZIYhaOFjG6zv0TWszdKvsaBcmgAVpph/ChLtzXt44l7lj9UA==
X-Received: by 2002:a05:600c:3b92:b0:475:dd04:1289 with SMTP id
5b1f17b1804b1-4776bcbac9fmr34139535e9.20.1762530786711;
Fri, 07 Nov 2025 07:53:06 -0800 (PST)
Received: from pro4 (p200300e0b7103700b9dd3d7a9e7f9444.dip0.t-ipconnect.de.
[2003:e0:b710:3700:b9dd:3d7a:9e7f:9444])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-42b29e4b9bdsm1694063f8f.32.2025.11.07.07.53.06
for <79782 <at> debbugs.gnu.org>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 07 Nov 2025 07:53:06 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: 79782 <at> debbugs.gnu.org
Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not
complete
In-Reply-To: <m2wm41onn1.fsf@HIDDEN>
References: <m2a50ynhkj.fsf@HIDDEN> <m2wm41onn1.fsf@HIDDEN>
Date: Fri, 07 Nov 2025 16:53:02 +0100
Message-ID: <m2tsz5on4x.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
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: 79782
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>
>> To reproduce, in an Emacs build with native compilation
>>
>> - emacs -Q
>> - C-x C-f <repo>/lisp/emacs-lisp/comp.el RET
>> - M-x emacs-lisp-native-compile RET
>>
>> The command does not complete. If one evaluates the buffer first, then
>> M-x toggle-debug-on-quit, and C-g, one can see that it is stuck
>> somewhere in the native compiler.
>>
>> In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin25.1.0, NS
>> appkit-2685.20 Version 26.1 (Build 25B78)) of 2025-11-07 built on pro4
>> Repository revision: be527b570465dad453f5aebba3c552f14ec98e2b
>> Repository branch: master
>> System Description: macOS 26.1
>>
>> Configured using:
>> 'configure --with-native-compilation --with-ns CC=3Dclang
>> 'CFLAGS=3D-Wgnu-imaginary-constant -Wunused-result -g
>> -Wno-ignored-attributes -Wno-flag-enum -Wno-missing-method-return-type
>> -Wno-variadic-macros -Wno-strict-prototypes -Wno-availability
>> -Wno-nullability-completeness -g -O2' --cache-file
>> /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.master'
>
> I went 3 years back for bisecting, but could not find a working good
> commit, sorry.
Many samples taken with macOS' Activity Monitor like this:
Call graph:
867 Thread_4055222 DispatchQueue_1: com.apple.main-thread (serial)
867 start (in dyld) + 7184 [0x19e161d54]
867 main (in emacs) + 8008 [0x104db18c0] emacs.c:2629
867 Frecursive_edit (in emacs) + 368 [0x104db2a70] keyboard.c:=
832
867 recursive_edit_1 (in emacs) + 164 [0x104db2718] keyboard=
.c:749
867 command_loop (in emacs) + 268 [0x104db28c8] keyboard.c=
:1141
867 internal_catch (in emacs) + 256 [0x104e3a788] eval.c=
:1370
867 command_loop_2 (in emacs) + 52 [0x104db30b0] keybo=
ard.c:1163
867 internal_condition_case (in emacs) + 260 [0x104e3=
b1c8] eval.c:1690
867 command_loop_1 (in emacs) + 828 [0x104db3400] =
keyboard.c:1424
867 read_key_sequence (in emacs) + 1380 [0x104db4=
de0] keyboard.c:11146
867 read_char (in emacs) + 6340 [0x104db81a8] =
keyboard.c:3020
867 wait_reading_process_output (in emacs) + 4=
200 [0x104e9a200] process.c:5810
867 thread_select (in emacs) + 84 [0x104ebd=
624] thread.c:659
867 really_call_select (in emacs) + 88 [0=
x104ebd6b0] thread.c:624
867 pselect$DARWIN_EXTSN (in libsystem_k=
ernel.dylib) + 64 [0x19e4ecf94]
867 __pselect (in libsystem_kernel.dyl=
ib) + 8 [0x19e4ed0bc]
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 15:42:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:42:24 2025 Received: from localhost ([127.0.0.1]:46428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHObX-0004uI-Nw for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:42:24 -0500 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:43389) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vHObS-0004tp-Bg for 79782 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:42:21 -0500 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-470ffbf2150so4315105e9.1 for <79782 <at> debbugs.gnu.org>; Fri, 07 Nov 2025 07:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762530132; x=1763134932; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:from:to:cc:subject:date :message-id:reply-to; bh=d8GtGiOwjUbuLMlNwUUFeWxY4Fq/wD8gGgJLYM+pHfU=; b=SSIboSfgKxxWsV+UIN6tFezOyp+UyEWakspWLqPQw3JkUAIdr0Frs1OHSi1u0f6SQg 5/pPCt7luuWxK1Tw9aG4FmLzC/KfkXooyt5M8uFPp3BdD3M6fBFAbdkE5TJ1PMWPIOpm n5pvE0jyOnkd2TaMiGFhMensMMPY20LL0ysdjESDtvnNDw7KbjP84mHLUy15a7mxirV2 uQW7mwNh8c6y4UQbkZh+2omH9J/W5bg4QFZOWAC1V7GAFI6ng0ei/S2TJ0+Kvb/0M0qp PBEtMiaKa34PVHBUHv7hQGfLUpJ08wuAPpJ2FtMLGh87Rk/MTNQ7lp/NS8UL/BXuz6JX QmWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762530132; x=1763134932; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:to:from:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=d8GtGiOwjUbuLMlNwUUFeWxY4Fq/wD8gGgJLYM+pHfU=; b=V4n4nfxijvuCU4lwL9XZrgK1HWKma4AEa0VuYO67HKb2it9RwkqIuIw0sbiLO0lbgu fT0VRVsW7qTKLNc/nYbvK+XbfbL1cUs2Iyfehwq3l1fyarlfkSwFZFjsCIauLdWjTWbD RX8athLBbkH/CgFw9oF097GGziNOQ6UAlZdFifGKF95hwhCw4jKt5IOV6YR1HtDrZ1VQ junU716IWllJG2nPL+bnA0ELbJVMyt0hCt9rDsA91yu2WFbBPbLyjkbgBogOclQnX5tM Fxce6zlqjfSDc0plGi4oMFidq4oR57vWvw9NO3jg7JEPrTnNDAiXOdKjTwf30bPZKSAs icoQ== X-Gm-Message-State: AOJu0YxWImn+z5wdetWmyt9x26rbnVL80xNSWf5Rn+AEUtgTgIixHhtM VBQZTjO5ATifiaDp251cxu6+5/xX8qgEN5LwtV1kYh1uKh+VTiavpNkkFqGsSWWi X-Gm-Gg: ASbGncsqANavDtEFOvIc5Aa2negeXHgOi8riATtgnkZ4fJ98Wt0M2PqNUrvyKRh0Bwt hOXERvircbnPp3VaUe4ayjVAK/M1XyXxIIl6IfXOJgoPWOjJeELtBh69vZrc5QXMqi/Dwrksb4a JF8xJbeCBsLqLmd4wPNh86ZU8FylwBIU5CsF6Jlu+jPlHzpAjnaBoeVKtEl/uVIhVP/8uwRlM40 FH79pZtDc0VfWuLAd5JHxplJPD1sXKtsGcLBS4BWMKKcyxZ69nkY1aUZBG6WBIAEspRHTpmdE/b syj75KI6dBo1DjcwI7uGFkamPyfXlNm4++2ZaeN4bO55cl7ZTp807zY5D6W4eZ9pqNy6A/911K4 5LQp3i6vSNJtp5PKZB1lFwaPOwxZ9H4VX+FOM1qtK997hXOkiBxqTz9mNtgvJ2TMpUalTYUoJWG 99FzqGup2+EnNlF24EDc/cPZsbPEG34mv7PRil2mnLvmH77qfBIEWduLGVJ6TZ3f0hK2Q3ywuBw v/3dld8Fyhwm+OpQSDg/o4= X-Google-Smtp-Source: AGHT+IHmYYY5JCRP5edLfehWTmoKtyzkOOMb2f2e8QQ5/T0pnjPArC4KhO4evSi41HzZ+gYMW4mC9A== X-Received: by 2002:a05:600c:450a:b0:475:d9de:952e with SMTP id 5b1f17b1804b1-4776dc11f92mr20592455e9.1.1762530131774; Fri, 07 Nov 2025 07:42:11 -0800 (PST) Received: from pro4 (p200300e0b7103700b9dd3d7a9e7f9444.dip0.t-ipconnect.de. [2003:e0:b710:3700:b9dd:3d7a:9e7f:9444]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4776bcdd8e3sm52384975e9.10.2025.11.07.07.42.11 for <79782 <at> debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Nov 2025 07:42:11 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: 79782 <at> debbugs.gnu.org Subject: Re: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete In-Reply-To: <m2a50ynhkj.fsf@HIDDEN> References: <m2a50ynhkj.fsf@HIDDEN> Date: Fri, 07 Nov 2025 16:42:10 +0100 Message-ID: <m2wm41onn1.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) 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: 79782 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > To reproduce, in an Emacs build with native compilation > > - emacs -Q > - C-x C-f <repo>/lisp/emacs-lisp/comp.el RET > - M-x emacs-lisp-native-compile RET > > The command does not complete. If one evaluates the buffer first, then > M-x toggle-debug-on-quit, and C-g, one can see that it is stuck > somewhere in the native compiler. > > In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin25.1.0, NS > appkit-2685.20 Version 26.1 (Build 25B78)) of 2025-11-07 built on pro4 > Repository revision: be527b570465dad453f5aebba3c552f14ec98e2b > Repository branch: master > System Description: macOS 26.1 > > Configured using: > 'configure --with-native-compilation --with-ns CC=3Dclang > 'CFLAGS=3D-Wgnu-imaginary-constant -Wunused-result -g > -Wno-ignored-attributes -Wno-flag-enum -Wno-missing-method-return-type > -Wno-variadic-macros -Wno-strict-prototypes -Wno-availability > -Wno-nullability-completeness -g -O2' --cache-file > /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.master' I went 3 years back for bisecting, but could not find a working good commit, sorry.
bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 7 Nov 2025 12:38:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 07:38:53 2025 Received: from localhost ([127.0.0.1]:45689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHLjx-0005iS-I7 for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:38:53 -0500 Received: from lists.gnu.org ([2001:470:142::17]:42022) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1vHLju-0005iI-KU for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:38:50 -0500 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 <gerd.moellmann@HIDDEN>) id 1vHLjo-0005z4-V1 for bug-gnu-emacs@HIDDEN; Fri, 07 Nov 2025 07:38:45 -0500 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <gerd.moellmann@HIDDEN>) id 1vHLjn-0001Vt-1K for bug-gnu-emacs@HIDDEN; Fri, 07 Nov 2025 07:38:44 -0500 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-641458f71ffso924531a12.3 for <bug-gnu-emacs@HIDDEN>; Fri, 07 Nov 2025 04:38:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1762519120; x=1763123920; darn=gnu.org; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=P82rTeVMEyfl11KjJt8IoHIy82g7kdMGPhMOvPIDy4U=; b=bPWzRhfsb0KmqFNZ1guiwbn8nfDpOCo1EDz67aXfDbTKB/2EuLRIgut92t7QFFS5aA LPDXycEigsjGiiDYSAcMR/BcXe2IJHdYe2i8I1/P3LzY3fVh0rIolWFFlbfjUSNS+Mfo L5ZX7ujzcl9ddDCAQhSkf38sN/lKPUUFWWNoCCeWs7su8s2z56bhhFDi6avVw3CpUSq9 w4/tp/N7D4l+IF0ch0XWRPi4W7TrHHv8Lk5s3y6k7khCSgfx2vUdB38ZTgKHCripR9Kd XXig6vHqRedfqlW4HdDrExxLdlrFucx+jiOeCmIeCnz2m+oQoHvLtAggS7N19ZPdcqCQ F5FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762519120; x=1763123920; h=mime-version:message-id:date:subject:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=P82rTeVMEyfl11KjJt8IoHIy82g7kdMGPhMOvPIDy4U=; b=RP0FgSRzwrvj/7AMlNsRsh53E9LNWX9FNbc1UbNc+tt7ylblUNFy6ffdSvZ5d6wfKG T+eXPK8oEw59wtUQeDvG5MLVFCLNTaGOCv339k7haZRjlUVrxBGcF52V0HH3RhChYOxd 0FhPxX0PgNSj4ATGjxZJmQDkUtTPLYuLdEEcLSeOSHZDTfxftns0oXW1aR92NfCIiBcC HiZLNxKead95ZYMUwlU0IppYQx4/Zq2TuCvWMMBUr8DcxMgtR1049oNFWaR7T/0/QNwG r2a5f0edYKDWk8My082KTAycizwbv0RJ1Ex8Uoc8lwDWy898KvbCi4g5PWaBvgCAikQn T2qQ== X-Gm-Message-State: AOJu0YxnUn7BI3jou7etK+TXW+Z5Y4BOOTWK/asYTOnxMcgGkEAnjV+e 3N0VI1gqhPC8YMfKAX8W66l+2V+QyhyHdVK60G+3JwxUrQNakxH5blv/fT4E4goo X-Gm-Gg: ASbGncvHXcNNEuYAIUdh683iorUXskFruJepPqwU5OhO4jxOIKHRooizJ8En/IprQ3u DiLO7+uj+gvVQCFPsgpjHnJnjtJTnWEP9+C3aB5mduo987oTtHTUz9BfU8nLsXma3NQMuILZ5bI p7YHFjEFNcuX+fwms9iQJr8+QxOK0I3KEEqFVHOmyKlSm36XWjbY3EyBz9bRjTkJr6Xw1AYh1I8 pSz03IpNIN1QFxU/o1MSqLhvqzlkZ8CMaQLpoK8YiRwZYWboGpmUzpgDHfGbYvkGH1dYf7iPpzD vpCynNZK4aYMyxIY0v/+zyRq+Z3c3DryLJu1dIRzlmWFnxA5tQBnnzDfG+4KSn3iUwtN65ZMvgy GsjYuO93M8IoVkLXGgnKvWuCET5CNmVq10ysyJwLNdcRXmat2WYJF7Seyy10hX4B+1dQCJVulmo m70P5ZwHxQwnKZhiJwCAmOIP07EvGMYFMDzAtcEviSyPr49E+swPz3TXU/USzxyyTTHnYKfNNXR emzDQWrgF5t41mX3m2cmg8H38fU19fKSQ== X-Google-Smtp-Source: AGHT+IEtqVDFw1rYPd+ca6U3XpdptQtU51uFbA05svBtmVxwNX46Zbq7OJWau88MhAx5BcCWkZmRVA== X-Received: by 2002:a17:906:794c:b0:b70:50f0:e6ae with SMTP id a640c23a62f3a-b72c0e3a44fmr285785366b.46.1762519120466; Fri, 07 Nov 2025 04:38:40 -0800 (PST) Received: from pro4 (p200300e0b7103700b9dd3d7a9e7f9444.dip0.t-ipconnect.de. [2003:e0:b710:3700:b9dd:3d7a:9e7f:9444]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b72bf97d461sm252902966b.47.2025.11.07.04.38.37 for <bug-gnu-emacs@HIDDEN> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 07 Nov 2025 04:38:39 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 31.0.50; M-x emacs-lisp-native-compile does not complete X-Debbugs-Cc: Date: Fri, 07 Nov 2025 13:38:36 +0100 Message-ID: <m2a50ynhkj.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::52f; envelope-from=gerd.moellmann@HIDDEN; helo=mail-ed1-x52f.google.com 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) To reproduce, in an Emacs build with native compilation - emacs -Q - C-x C-f <repo>/lisp/emacs-lisp/comp.el RET - M-x emacs-lisp-native-compile RET The command does not complete. If one evaluates the buffer first, then M-x toggle-debug-on-quit, and C-g, one can see that it is stuck somewhere in the native compiler. In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin25.1.0, NS appkit-2685.20 Version 26.1 (Build 25B78)) of 2025-11-07 built on pro4 Repository revision: be527b570465dad453f5aebba3c552f14ec98e2b Repository branch: master System Description: macOS 26.1 Configured using: 'configure --with-native-compilation --with-ns CC=clang 'CFLAGS=-Wgnu-imaginary-constant -Wunused-result -g -Wno-ignored-attributes -Wno-flag-enum -Wno-missing-method-return-type -Wno-variadic-macros -Wno-strict-prototypes -Wno-availability -Wno-nullability-completeness -g -O2' --cache-file /var/folders/1d/k_6t25f94sl83szqbf8gpkrh0000gn/T//config.cache.master'
Gerd Möllmann <gerd.moellmann@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#79782; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.