GNU logs - #79782, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Nov 2025 12:39:01 +0000
Resent-Message-ID: <handler.79782.B.176251913421980 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 79782 <at> debbugs.gnu.org
From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
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-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'

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Subject: bug#79782: Acknowledgement (31.0.50; M-x emacs-lisp-native-compile
 does not complete)
Message-ID: <handler.79782.B.176251913421980.ack <at> debbugs.gnu.org>
References: <m2a50ynhkj.fsf@HIDDEN>
X-Gnu-PR-Message: ack 79782
X-Gnu-PR-Package: emacs
Reply-To: 79782 <at> debbugs.gnu.org
Date: Fri, 07 Nov 2025 12:39:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 79782 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
79782: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D79782
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Nov 2025 15:43:02 +0000
Resent-Message-ID: <handler.79782.B79782.176253014418870 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 79782 <at> debbugs.gnu.org
From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Nov 2025 15:54:01 +0000
Resent-Message-ID: <handler.79782.B79782.176253079720396 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 79782 <at> debbugs.gnu.org
From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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]

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Pip Cet <pipcet@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Nov 2025 17:39:01 +0000
Resent-Message-ID: <handler.79782.B79782.176253710826283 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Cc: 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.176253710826283
          (code B ref 79782); Fri, 07 Nov 2025 17:39:01 +0000
Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 17:38:28 +0000
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
From: Pip Cet <pipcet@HIDDEN>
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-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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Nov 2025 18:10:02 +0000
Resent-Message-ID: <handler.79782.B79782.176253895630313 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Pip Cet <pipcet@HIDDEN>
Cc: 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.176253895630313
          (code B ref 79782); Fri, 07 Nov 2025 18:10:02 +0000
Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 18:09:16 +0000
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: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
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-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.

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 7 Nov 2025 18:10:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 13:10:43 2025
Received: from localhost ([127.0.0.1]:47443 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1vHQv5-00080I-Aq
	for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 13:10:43 -0500
Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]:54289)
 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 1vHQv3-000806-63
 for control <at> debbugs.gnu.org; Fri, 07 Nov 2025 13:10:41 -0500
Received: by mail-ej1-x629.google.com with SMTP id
 a640c23a62f3a-b72cbc24637so177912666b.0
 for <control <at> debbugs.gnu.org>; Fri, 07 Nov 2025 10:10:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1762539035; x=1763143835; darn=debbugs.gnu.org;
 h=content-transfer-encoding:mime-version:subject:from:to:message-id
 :date:from:to:cc:subject:date:message-id:reply-to;
 bh=xRLAbWuy3xDCz+bE6AzCqIxZCoabhNv0E9+crtUvoW8=;
 b=dRSQFCzbcw3HZtcP7+4R0ZdRsnd/L0fe+a6wmcltgFjxmIo/zS4D08CuId5BwAWBaO
 65U8aBUYuVAfOgWMUFNQNpZliAcmrLapNGpz8Xw4uqbEOEnongJI6iBL7GXfcASM1Jbs
 a/Of6dvHhQicoE4vh7zkSLb4uMiIDSBX6D/KikzGqBWDKWUYFkI9lzZguW2WU94Dbhiw
 IHFgpsrpg3qVADgZb55ZOtKjAD4gq3hHP1u4cvqeZXEyhZpU18b7qdh3T3DVnYBi4XdJ
 ExjrN+PXBEcpt6wPCJ01vkqZbeWBgJsdrgGU54qpmf+tc5oCmVqOZnYk6frCUDiuE3vU
 nQfQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1762539035; x=1763143835;
 h=content-transfer-encoding:mime-version:subject:from:to:message-id
 :date:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=xRLAbWuy3xDCz+bE6AzCqIxZCoabhNv0E9+crtUvoW8=;
 b=LDTLbc8QMMI3EfoaWcdFPDHKHvFfwfeahLVsNYlOoj3Dv5uhRahUPTPIs4L4bRJMGk
 q6lf6F3rdQsxfBmSqVyQQr49WKjqvkxmtCXeigReRjwcPR5nata88iTMLIEOiXBzAKu2
 a041sNm7SwYkDcVe/by4SzlJsoXFDrcn6ASKXre6oWzOvX4ZykSp6o5xWJyu5OIX4N/j
 exdhNhqMfHFdA/EWL3pqyOfNm3tAlNF1v6EtiMEZGYlewJrFit2WEGjRYz/cbvWC+rSv
 YYX8rIB0tsqTHYMGElVa28xzwcj8a9WKlBHPtZ0bQ0dYEEV+d8ERrvKZ23a78rSfd+N/
 NS7A==
X-Gm-Message-State: AOJu0YwepGz7i0lKf1FvOcz8DxftSj5SLMrAOZkoevZwTKFqZCP5fijn
 GYsSACFfSC6mNZstzHtVhqmyJ+39eeNrs3MFt47g6hW0N7uWOtgE6YUMq168tfLO
X-Gm-Gg: ASbGncuHsccZt8hdKiHW+DMmM3WAwD93DOClyv7U1VR2KK0CthO0tUAQ56hqsHWI3n4
 bmfw9waVUeB7Dtx939Bu3DJBzhbjRQ5qXqSv6W2SDvvzQO45eFJMVhqfwSFsg4VoU3KuDJvWjtD
 9tprsB2wzGqvqxCZlx0KlDxhhqP1QpH8sJJ5K4SoeYmOklkaaz9Wi6GMcOfM4x3qeVz//xZvs7D
 trUggEEZB1z1GDrXlWq3Rg6pBOzAnrAbfEWpb/dZJriQ+rj+GiJBJ8plQaVQfs1GWAbraS2Mf/G
 I/tgNGAT0umBHNTDqhfXssrEjjqzRbMZj5z3KKL+FA9jGL19dZIzzc7WT/KvbpP6nQUfXTSBqHa
 BIIHnRbYJcCX6TNPZn79YslfSOC0Andjp+3ZMOetQRSPAKB7e42ygMeqkxKiXzAvYxmjvhLAa4Q
 DMXbuVTbQs31C24NyOgGR/mqZU6iDnwZtdr8GMUD3x2gYlGzmRpkLfF2egyG2o6rpBCaHnDNe7q
 Rn7obf8FpQz
X-Google-Smtp-Source: AGHT+IGvyMzTcK4CBgv+n4I/gIaBH7QUlT7ji5DQ/CAmM6n0Dsgdh8JBbdcyyewYo0fYTovv+Ht3xA==
X-Received: by 2002:a17:906:730e:b0:b70:b7f8:868f with SMTP id
 a640c23a62f3a-b72e036bbebmr21894466b.27.1762539034525; 
 Fri, 07 Nov 2025 10:10:34 -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-b72dbe7c783sm67661466b.50.2025.11.07.10.10.33
 for <control <at> debbugs.gnu.org>
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 07 Nov 2025 10:10:34 -0800 (PST)
Date: Fri, 07 Nov 2025 19:10:30 +0100
Message-Id: <m2ldkhogrt.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Subject: control message for bug #79782
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
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 (-)

close 79782 31.1
quit

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Pip Cet <pipcet@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Nov 2025 19:29:02 +0000
Resent-Message-ID: <handler.79782.B79782.176254371719860 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Cc: 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.176254371719860
          (code B ref 79782); Fri, 07 Nov 2025 19:29:02 +0000
Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 19:28:37 +0000
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
From: Pip Cet <pipcet@HIDDEN>
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-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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 07 Nov 2025 19:57:01 +0000
Resent-Message-ID: <handler.79782.B79782.176254540224885 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Pip Cet <pipcet@HIDDEN>
Cc: 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.176254540224885
          (code B ref 79782); Fri, 07 Nov 2025 19:57:01 +0000
Received: (at 79782) by debbugs.gnu.org; 7 Nov 2025 19:56:42 +0000
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: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
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-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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 08 Nov 2025 08:13:01 +0000
Resent-Message-ID: <handler.79782.B79782.17625895365541 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Pip Cet <pipcet@HIDDEN>
Cc: 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.17625895365541
          (code B ref 79782); Sat, 08 Nov 2025 08:13:01 +0000
Received: (at 79782) by debbugs.gnu.org; 8 Nov 2025 08:12:16 +0000
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: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@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>
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-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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Pip Cet <pipcet@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 08 Nov 2025 08:19:02 +0000
Resent-Message-ID: <handler.79782.B79782.17625898856299 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Cc: 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.17625898856299
          (code B ref 79782); Sat, 08 Nov 2025 08:19:02 +0000
Received: (at 79782) by debbugs.gnu.org; 8 Nov 2025 08:18:05 +0000
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
From: Pip Cet <pipcet@HIDDEN>
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-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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 08 Nov 2025 08:27:01 +0000
Resent-Message-ID: <handler.79782.B79782.17625903977755 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Pip Cet <pipcet@HIDDEN>
Cc: 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.17625903977755
          (code B ref 79782); Sat, 08 Nov 2025 08:27:01 +0000
Received: (at 79782) by debbugs.gnu.org; 8 Nov 2025 08:26:37 +0000
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: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
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-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 :-)).

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 08 Nov 2025 08:46:01 +0000
Resent-Message-ID: <handler.79782.B79782.176259154911501 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Pip Cet <pipcet@HIDDEN>, Andrea Corallo <acorallo@HIDDEN>
Cc: gerd.moellmann@HIDDEN, 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.176259154911501
          (code B ref 79782); Sat, 08 Nov 2025 08:46:01 +0000
Received: (at 79782) by debbugs.gnu.org; 8 Nov 2025 08:45:49 +0000
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>
In-Reply-To: <87v7jlx7iw.fsf@HIDDEN> (bug-gnu-emacs@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>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
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
> 
> 
> 
> 
> 
>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Nov 2025 09:03:02 +0000
Resent-Message-ID: <handler.79782.B79782.176328374213065 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Gerd =?UTF-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Cc: Pip Cet <pipcet@HIDDEN>, 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.176328374213065
          (code B ref 79782); Sun, 16 Nov 2025 09:03:02 +0000
Received: (at 79782) by debbugs.gnu.org; 16 Nov 2025 09:02:22 +0000
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>
In-Reply-To: <m2frapobv5.fsf@HIDDEN> ("Gerd =?UTF-8?Q?M=C3=B6llmann?="'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-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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Andrea Corallo <acorallo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Nov 2025 09:35:02 +0000
Resent-Message-ID: <handler.79782.B79782.176328569418441 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: gerd.moellmann@HIDDEN, Pip Cet <pipcet@HIDDEN>, 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.176328569418441
          (code B ref 79782); Sun, 16 Nov 2025 09:35:02 +0000
Received: (at 79782) by debbugs.gnu.org; 16 Nov 2025 09:34:54 +0000
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>
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-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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#79782: 31.0.50; M-x emacs-lisp-native-compile does not complete
Resent-From: Pip Cet <pipcet@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 25 Nov 2025 20:17:23 +0000
Resent-Message-ID: <handler.79782.B79782.176410182220098 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 79782
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrea Corallo <acorallo@HIDDEN>
Cc: gerd.moellmann@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 79782 <at> debbugs.gnu.org
Received: via spool by 79782-submit <at> debbugs.gnu.org id=B79782.176410182220098
          (code B ref 79782); Tue, 25 Nov 2025 20:17:23 +0000
Received: (at 79782) by debbugs.gnu.org; 25 Nov 2025 20:17:02 +0000
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
From: Pip Cet <pipcet@HIDDEN>
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-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

Last modified: Tue, 25 Nov 2025 20:30:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.