bug#46502: 28.0.50; [feature/native-comp] (d3a399dd) native-comp bootstrap failure

[Andrea Corallo]

Pip Cet <pipcet@gmail.com> writes:

> On Thu, Feb 18, 2021 at 10:04 AM Andrea Corallo via Bug reports for
> GNU Emacs, the Swiss army knife of text editors
> <bug-gnu-emacs@gnu.org> wrote:
>> Michael Welsh Duggan <mwd@md5i.com> writes:
>> > I decided to attempt building the native-comp feature branch, since it
>> > seems like it may make it to mainline fairly soon.  When bootstrapping
>> > with
>> >
>> >   make NATIVE_FULL_AOT=1 -j 32 bootstrap
>> >
>> > I get an error compiling gnus/gnus-icalendar.el.  I've put the log
>> > below.  I've updated the emacs information from my running emacs below
>> > to match the version of the repository from which I built.
>> >
>> >
>> > In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo 
>> > version 1.16.0)
>> >  of 2021-02-13 built on miko
>> > Repository revision: d3a399dd299bf7e811cf42950d5f8ac67f063b36
>> > Repository branch: native-comp
>> > Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
>> > System Description: Debian GNU/Linux bullseye/sid
>> >
>> > Configured using:
>> >  'configure --without-toolkit-scroll-bars --with-x-toolkit=lucid 
>> > --with-nativecomp'
>> >
>> >
>> > Debugger entered--Lisp error: (error "Lisp nesting exceeds 
>> > ‘max-lisp-eval-depth’")
>>
>> Hi Michael,
>>
>> just tried compiling the current branch (f92bb788a0) following your
>> configuration with no issues.  Could you retry on the current head maybe
>> starting from a "git clean -xfd" to be on the safe side?
>
> One thing I've noticed in my experiments is that many builds that are
> interrupted at the wrong point and then resumed produce different
> results. I.e. you type "make", then hit Ctrl-C at the wrong time, then
> type "make" again and you get a different result.
>
> We should fix that, and it might lead to the behavior Michael has
> observed (macroexp being executed from source code when compiling
> gnus)...
>
> BTW, I'm also seeing very deep recursion when building the nativecomp
> branch, even outside of the garbage collector (which is easy to "fix"
> so it allocates more than one object at the same time on the C stack).
> Maybe we can avoid that by doing an -O0 compile first, then compiling
> the optimized compiler with the unoptimized one?

Agree, I think might be even better in terms of bootstrap time to just
byte compile the initial COMPILE_FIRST files and then re-compiling and
loading them nativelly later-on (before dumping).

Never had time to tackle this.

  Andrea