bug#58509: 29.0.50; Synchronous nativecomp

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: larsi@gnus.org, 58509@debbugs.gnu.org
>> Date: Wed, 19 Oct 2022 19:02:59 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Andrea Corallo <akrl@sdf.org>
>> >> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 58509@debbugs.gnu.org
>> >> Date: Tue, 18 Oct 2022 13:55:18 +0000
>> >> 
>> >> The attached works for me for fixing the trampoline issue (unless I did
>> >> something wrong reproducing).
>> >> 
>> >> I named the flag -no-comp-spawn from the variable it controls.  Happy to
>> >> rename it if we have something better, but being for internal use only
>> >> maybe is already okay?
>> >
>> > On second thought: why do we need a special knob for that?  Could we
>> > instead _always_ compile trampolines "without spawning" in a --batch
>> > session?
>> 
>> Hi Eli,
>> 
>> unfortunately we cannot as libgccjit leaks memory :/
>
> I think there could be a misunderstanding here.  What I meant is to do
> whatever we do under -no-comp-spawn, but do it always for trampolines
> in the --batch invocations, without the need to see -no-comp-spawn on
> the command line.

> "do it always for trampolines in the --batch invocations"

So you mean identifying that we are doing a trampoline compilation and
disable the native compiler without a specific flag?

But I'm not sure I understand 100%, hope the explaination that follows
helps clarifying.

> Or maybe I misunderstand what -no-comp-spawn does, in which case can
> you tell me what I missed?

-no-comp-spawn makes sure that in the spawend compilation processes, no
 matter what, we never spawn again other compilation processes.

We have two invocations for spawning processes, one for sync
compilations and one of async (none of the invocation is specific to
trampolines).  This patch is using -no-comp-spawn for both.

  Andrea