GNU bug report logs -
#44209
28.0.50; [feature/native-comp] Compilation failure in progmodes/js.el
Previous Next
Reported by: Andrew Whatson <whatson <at> gmail.com>
Date: Sun, 25 Oct 2020 11:07:02 UTC
Severity: normal
Tags: moreinfo
Found in version 28.0.50
Done: Andrea Corallo <akrl <at> sdf.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44209 in the body.
You can then email your comments to 44209 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 11:07:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Andrew Whatson <whatson <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sun, 25 Oct 2020 11:07:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The latest merge from master included commit 30305b54, which causes
NATIVE_FULL_AOT builds to fail with the following error:
progmodes/js.el:4550:11: Error: Symbol’s function definition is void:
cc-bytecomp-is-compiling
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 13:17:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Andrew Whatson <whatson <at> gmail.com> writes:
> The latest merge from master included commit 30305b54, which causes
> NATIVE_FULL_AOT builds to fail with the following error:
>
> progmodes/js.el:4550:11: Error: Symbol’s function definition is void:
> cc-bytecomp-is-compiling
I'm unable to reproduce this bug. Have you tried a "make bootstrap" (or
perhaps just deleting lisp/progmodes/js.elc)?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sun, 25 Oct 2020 13:17:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 13:54:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> I'm unable to reproduce this bug. Have you tried a "make bootstrap" (or
> perhaps just deleting lisp/progmodes/js.elc)?
I see this error with Guix builds
(https://github.com/flatwhatson/guix-channel) and AUR builds
(https://aur.archlinux.org/packages/emacs-native-comp-git/), both of
which are completely clean.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 14:26:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Andrew Whatson <whatson <at> gmail.com> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>
>> I'm unable to reproduce this bug. Have you tried a "make bootstrap" (or
>> perhaps just deleting lisp/progmodes/js.elc)?
>
> I see this error with Guix builds
> (https://github.com/flatwhatson/guix-channel) and AUR builds
> (https://aur.archlinux.org/packages/emacs-native-comp-git/), both of
> which are completely clean.
Oh, you're compiling the archlinux package, not from Emacs git?
There are no errors when saying "make bootstrap" from the Emacs git
native-comp branch, so I guess you should take this up with the archlinux
people?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 14:43:03 GMT)
Full text and
rfc822 format available.
Message #19 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Oh, you're compiling the archlinux package, not from Emacs git?
>
> There are no errors when saying "make bootstrap" from the Emacs git
> native-comp branch, so I guess you should take this up with the archlinux
> people?
I maintain both of these packages. Are you sure you're testing with
"make NATIVE_FULL_AOT=1"? The error does not occur with the minimal
bootstrap build, because that doesn't attempt to native-compile js.el
during the build. I guess this error must occur at runtime with
deferred compilation for non-AOT builds.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 14:56:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Andrew Whatson <whatson <at> gmail.com> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>
>> Oh, you're compiling the archlinux package, not from Emacs git?
>>
>> There are no errors when saying "make bootstrap" from the Emacs git
>> native-comp branch, so I guess you should take this up with the archlinux
>> people?
>
> I maintain both of these packages. Are you sure you're testing with
> "make NATIVE_FULL_AOT=1"? The error does not occur with the minimal
> bootstrap build, because that doesn't attempt to native-compile js.el
> during the build. I guess this error must occur at runtime with
> deferred compilation for non-AOT builds.
Hi Andrew,
just got the same error here with NATIVE_FULL_AOT=1. Do you know if
it's reliably reproducible or just happens from time to time?
Thanks
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 15:03:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Andrew Whatson <whatson <at> gmail.com> writes:
> I maintain both of these packages. Are you sure you're testing with
> "make NATIVE_FULL_AOT=1"? The error does not occur with the minimal
> bootstrap build, because that doesn't attempt to native-compile js.el
> during the build. I guess this error must occur at runtime with
> deferred compilation for non-AOT builds.
Oh, sorry, I assumed that
ELC+ELN progmodes/js.elc
meant that it was doing full ahead-of-time .eln generation... but it's
not? Andrea, perhaps the compilation output here should be tweaked,
then?
Anyway, with
$ make -j16 NATIVE_FULL_AOT=1 bootstrap
I do get the same error you're seeing:
ELC+ELN progmodes/js.elc
Symbol's function definition is void: cc-bytecomp-is-compiling
make[3]: *** [Makefile:314: progmodes/js.elc] Error 255
make[3]: Leaving directory '/home/larsi/src/emacs/native-compile/lisp'
make[2]: *** [Makefile:348: compile-main] Error 2
make[2]: Leaving directory '/home/larsi/src/emacs/native-compile/lisp'
make[1]: *** [Makefile:420: lisp] Error 2
make[1]: Leaving directory '/home/larsi/src/emacs/native-compile'
make: *** [Makefile:1143: bootstrap] Error 2
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 15:12:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <akrl <at> sdf.org> wrote:
> just got the same error here with NATIVE_FULL_AOT=1. Do you know if
> it's reliably reproducible or just happens from time to time?
Hi Andrea, this error occurs consistently for me when performing an
AOT build. Reverting 30305b54 allows the build to complete, and that
commit introduced the explicit ordering between js and cc modes which
uncovers this bug.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 15:22:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Andrew Whatson <whatson <at> gmail.com> writes:
> Andrea Corallo <akrl <at> sdf.org> wrote:
>
>> just got the same error here with NATIVE_FULL_AOT=1. Do you know if
>> it's reliably reproducible or just happens from time to time?
>
> Hi Andrea, this error occurs consistently for me when performing an
> AOT build. Reverting 30305b54 allows the build to complete, and that
> commit introduced the explicit ordering between js and cc modes which
> uncovers this bug.
Nice, I'll have look.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 15:31:02 GMT)
Full text and
rfc822 format available.
Message #34 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Andrew Whatson <whatson <at> gmail.com> writes:
>
>> I maintain both of these packages. Are you sure you're testing with
>> "make NATIVE_FULL_AOT=1"? The error does not occur with the minimal
>> bootstrap build, because that doesn't attempt to native-compile js.el
>> during the build. I guess this error must occur at runtime with
>> deferred compilation for non-AOT builds.
>
> Oh, sorry, I assumed that
>
> ELC+ELN progmodes/js.elc
>
> meant that it was doing full ahead-of-time .eln generation... but it's
> not? Andrea, perhaps the compilation output here should be tweaked,
> then?
Correct we are printing ELC+ELN even when we are native compiling only
the files involved in the image creation + few others (the default
setting).
I agree would be nice to have it tweaked for when we are not doing a
full AoT compilation.
I'll have a look into.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 15:58:01 GMT)
Full text and
rfc822 format available.
Message #37 received at submit <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Andrew Whatson <whatson <at> gmail.com> writes:
>>
>>> I maintain both of these packages. Are you sure you're testing with
>>> "make NATIVE_FULL_AOT=1"? The error does not occur with the minimal
>>> bootstrap build, because that doesn't attempt to native-compile js.el
>>> during the build. I guess this error must occur at runtime with
>>> deferred compilation for non-AOT builds.
>>
>> Oh, sorry, I assumed that
>>
>> ELC+ELN progmodes/js.elc
>>
>> meant that it was doing full ahead-of-time .eln generation... but it's
>> not? Andrea, perhaps the compilation output here should be tweaked,
>> then?
>
> Correct we are printing ELC+ELN even when we are native compiling only
> the files involved in the image creation + few others (the default
> setting).
>
> I agree would be nice to have it tweaked for when we are not doing a
> full AoT compilation.
>
> I'll have a look into.
I pushed 868d3ff9b8, should do the job.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 15:58:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 16:14:02 GMT)
Full text and
rfc822 format available.
Message #43 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <akrl <at> sdf.org> writes:
>> I agree would be nice to have it tweaked for when we are not doing a
>> full AoT compilation.
>>
>> I'll have a look into.
>
> I pushed 868d3ff9b8, should do the job.
Thanks, looks good now. And it looks like this is erroring out not when
compiling js.el, but when cc-mode has been natively compiled?
$ make
....
make[2]: Entering directory '/home/larsi/src/emacs/native-compile/lisp'
ELC progmodes/js.elc
In toplevel form:
progmodes/js.el:4550:11: Error: Symbol’s function definition is void: cc-bytecomp-is-compiling
make[2]: *** [Makefile:318: progmodes/js.elc] Error 1
make[2]: Leaving directory '/home/larsi/src/emacs/native-compile/lisp'
make[1]: *** [Makefile:352: compile-main] Error 2
make[1]: Leaving directory '/home/larsi/src/emacs/native-compile/lisp'
make: *** [Makefile:420: lisp] Error 2
cc-bytecomp-is-compiling is a defsubst, if that's any clue. The
following patch fixes the problem, but I'm not sure... why...
diff --git a/lisp/progmodes/js.el b/lisp/progmodes/js.el
index f3cfbbb948..563bf88e6a 100644
--- a/lisp/progmodes/js.el
+++ b/lisp/progmodes/js.el
@@ -48,6 +48,7 @@
(require 'cc-mode)
(eval-when-compile
(require 'cc-langs)
+ (require 'cc-bytecomp)
(require 'cc-fonts))
(require 'newcomment)
(require 'imenu)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 21:44:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Okay I think I see what is going on:
We fail to inline `cc-bytecomp-is-compiling' inside cc-defs.el because
`cc-bytecomp-is-compiling' is native compiled even if it should not.
We do not native compile defsubsts so they can be disassebled by the
bytecompiler to have the inlining performed effectively.
Prove of this is that adding (declare (speed -1)) to
`cc-bytecomp-is-compiling' to prevent native compialtion fix the
issue.
Now why defsubst is failing to do the same automatically is another
question I have to look into. I suspect this issue is also the cause
of some of the warnings we see during the native build.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 23:08:02 GMT)
Full text and
rfc822 format available.
Message #49 received at submit <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> Okay I think I see what is going on:
>
> We fail to inline `cc-bytecomp-is-compiling' inside cc-defs.el because
> `cc-bytecomp-is-compiling' is native compiled even if it should not.
> We do not native compile defsubsts so they can be disassebled by the
> bytecompiler to have the inlining performed effectively.
>
> Prove of this is that adding (declare (speed -1)) to
> `cc-bytecomp-is-compiling' to prevent native compialtion fix the
> issue.
>
> Now why defsubst is failing to do the same automatically is another
> question I have to look into. I suspect this issue is also the cause
> of some of the warnings we see during the native build.
All right 5edc7aa019 fix the issue for me. I've also added a testcase
so hopefully we have it under control for the future.
Andrea
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 23:08:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Sun, 25 Oct 2020 23:46:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <akrl <at> sdf.org> writes:
> All right 5edc7aa019 fix the issue for me. I've also added a testcase
> so hopefully we have it under control for the future.
Yup; fixes it here, too (with a "make -j8 NATIVE_FULL_AOT=1 bootstrap").
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#44209
; Package
emacs
.
(Mon, 26 Oct 2020 01:09:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 44209 <at> debbugs.gnu.org (full text, mbox):
Andrea Corallo <akrl <at> sdf.org> wrote:
> All right 5edc7aa019 fix the issue for me.
Thanks Andrea, this is working for me.
Reply sent
to
Andrea Corallo <akrl <at> sdf.org>
:
You have taken responsibility.
(Mon, 26 Oct 2020 07:38:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Andrew Whatson <whatson <at> gmail.com>
:
bug acknowledged by developer.
(Mon, 26 Oct 2020 07:38:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 44209-done <at> debbugs.gnu.org (full text, mbox):
Super, thanks both for testing.
Closing it
Andrea
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 23 Nov 2020 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 267 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.