emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The emacs-28 release branch has been created


From: Andrea Corallo
Subject: Re: The emacs-28 release branch has been created
Date: Tue, 05 Oct 2021 15:43:27 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: kbrown@cornell.edu, emacs-devel@gnu.org
>> Date: Mon, 04 Oct 2021 19:38:43 +0000
>> 
>> - I reduced the reproducer searching manually by bissection in the file
>>   for the function causing the ICE
>
> So the problem caused an ICE in libgccjit, is that right?  Is that
> always so when the error message says
>
>   Lisp error: (native-compiler-error ...
>
> ?  Because the error message then said "(invalid-read-syntax...",
> which sounds like a message coming from Emacs, not from the compiler.

No we ICE in the lisp side of the native compiler.  Actually we ICEd in
the sub process when this tried to read the input lisp file we generate
(as truncated).

> Also, we probably want to avoid the ellipsis in batch invocations,
> because (unlike in interactive usage) they cannot be expanded.  Is
> that something that comp.el controls, or is that a general "feature"
> of Emacs?

The second.  Agree on the benefit of avoiding the ellipsis or making the
information longer befor truncation.

>> - I read carefully the stack trace of the compiler (after having posted
>>   it here :/ ) and saw that the reader error was not on file being
>>   compiled but on the file that we use to drive the native compilation
>>   happening in the subprocess (the one generated by `comp-final').
>
> How did you see that?  The backtrace says:
>
>> akrl@xxx:~/emacs2/lisp$ ../src/emacs -batch --no-site-file --no-site-lisp 
>> --eval '(setq load-prefer-newer t)' -l comp -f 
>> byte-compile-refresh-preloaded --eva\
>> l '(batch-native-compile t)' disp-table.el
>> Debugger entered--Lisp error: (native-compiler-error "disp-table.el" 
>> "Debugger entered--Lisp error: (end-of-file \"/tmp/e...")
>>   signal(native-compiler-error ("disp-table.el" "Debugger entered--Lisp 
>> error: (end-of-file \"/tmp/e..."))
>>   comp--native-compile("disp-table.el")
>>   batch-native-compile(t)
>>   command-line-1(("--eval" "(setq load-prefer-newer t)" "-l" "comp" "-f" 
>> "byte-compile-refresh-preloaded" "--eval" "(batch-native-compile t)" 
>> "disp-table.el"))
>>   command-line()
>>   normal-top-level()
>
> So it only says "end of file", and the file name is not spelled out.

As name it reports /tmp/e... so it really looked like one of the
temporary input files we generate for child compilations and certainly
not the file I was trying to compile.

> And btw, this backtrace is different from what I saw originally: that
> one didn't say "end of file".  Why this one did?

Dunno for sure but I just guess the truncation happend in a different
point of the buffer.

>> - I looked into one of these files and I saw clearly in the limple dump
>>   a constant vector that is truncated (not sure why maybe we have to
>>   bind some other print-something var in comp final?).
>
> I'd like to understand why stuff gets truncated in that case.

Sure that's still the open question.

Best Regards

  Andrea



reply via email to

[Prev in Thread] Current Thread [Next in Thread]