* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
@ 2021-04-09 14:27 ` tomas
2021-04-09 14:33 ` Stefan Kangas
` (11 subsequent siblings)
12 siblings, 0 replies; 58+ messages in thread
From: tomas @ 2021-04-09 14:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Andrea Corallo, emacs-devel
[-- Attachment #1: Type: text/plain, Size: 302 bytes --]
On Fri, Apr 09, 2021 at 05:02:15PM +0300, Eli Zaretskii wrote:
> AFAICT, we are quite ready to land this important feature [...]
\o/
> Last, but not least: I'd like to take this opportunity to thank Andrea
> for his hard work [...]
Seconded, and thirded and...
Really impressive work.
Cheers
- t
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
2021-04-09 14:27 ` tomas
@ 2021-04-09 14:33 ` Stefan Kangas
2021-04-09 14:39 ` T.V Raman
` (10 subsequent siblings)
12 siblings, 0 replies; 58+ messages in thread
From: Stefan Kangas @ 2021-04-09 14:33 UTC (permalink / raw
To: Eli Zaretskii, emacs-devel; +Cc: Andrea Corallo
Eli Zaretskii <eliz@gnu.org> writes:
> If no significant issues pop up within a week, I will ask Andrea to
> merge the branch onto master the next weekend (i.e. around 17th of
> April).
Fantastic news! Thank you so much Andrea for all the hard work to make
this happen, and congratulations for finally getting it merged to
master.
Thanks also to Eli for reviewing the branch and moving the merge
forward.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
2021-04-09 14:27 ` tomas
2021-04-09 14:33 ` Stefan Kangas
@ 2021-04-09 14:39 ` T.V Raman
2021-04-09 16:17 ` Pip Cet
` (9 subsequent siblings)
12 siblings, 0 replies; 58+ messages in thread
From: T.V Raman @ 2021-04-09 14:39 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, Andrea Corallo
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1494 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
1+ on all counts. About a couple of months ago (perhaps longer) older
packages that used defmacro -- specifically the VM mail reader broke in
a couple of places, I remember sending Andrea email. Do we know if those
issues were fixed (Andrea would know)
And yes, this is really nice work and would be great to see it land.
> AFAICT, we are quite ready to land this important feature. The branch
> was tested on several systems and is in good shape: many issues and
> bugs were fixed, and currently no known issues remain that block the
> merge. (There's a lot yet to do wrt documenting the feature and its
> various aspects, but that can be done on master after merging.)
>
> If some of you have some unusual or rare or exotic system or Emacs
> configuration, and did not yet try building the native-comp branch,
> this is your chance to have a go before the merge: please build the
> branch and report any issues or problems you bump into.
>
> If no significant issues pop up within a week, I will ask Andrea to
> merge the branch onto master the next weekend (i.e. around 17th of
> April).
>
> Last, but not least: I'd like to take this opportunity to thank Andrea
> for his hard work and perseverance during this last year. We would
> not be where we are now with this feature without his devotion and
> determination to see this through. Thanks a lot!
>
--
Thanks,
--Raman
7©4 Id: kg:/m/0285kf1 0Ü8
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (2 preceding siblings ...)
2021-04-09 14:39 ` T.V Raman
@ 2021-04-09 16:17 ` Pip Cet
2021-04-09 16:35 ` Thierry Volpiatto
` (8 subsequent siblings)
12 siblings, 0 replies; 58+ messages in thread
From: Pip Cet @ 2021-04-09 16:17 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Andrea Corallo, emacs-devel
On Fri, Apr 9, 2021 at 2:04 PM Eli Zaretskii <eliz@gnu.org> wrote:
> AFAICT, we are quite ready to land this important feature. The branch
> was tested on several systems and is in good shape: many issues and
> bugs were fixed, and currently no known issues remain that block the
> merge. (There's a lot yet to do wrt documenting the feature and its
> various aspects, but that can be done on master after merging.)
There are still (theoretical, at least) miscompilation bugs, last I
checked. I don't think these should block the merge and there's plenty
of time to fix them on the master branch.
I must say I'm unhappy with many of the changes that are introduced
outside of comp.c/comp.el (asynchronous compilation as a
default/forced-on-users feature, the .eln handling, the way
natively-compiled functions are subrs even though they have virtually
nothing in common with them...). But, again, that's also something
that can be discussed more reasonably once the branch has been merged,
and there's perhaps less of an attitude of owning the branch.
I also think that it would be reasonable to merge only the "essential"
native-compilation features at first, and leaving out things like the
half-written SSA optimizer that's currently on the branch (or was last
I checked). But my understanding is Andrea is unwilling to consider
this option, and it's much better to have a master branch that Andrea
continues to work on.
> If no significant issues pop up within a week, I will ask Andrea to
> merge the branch onto master the next weekend (i.e. around 17th of
> April).
Hooray!
> Last, but not least: I'd like to take this opportunity to thank Andrea
> for his hard work and perseverance during this last year. We would
> not be where we are now with this feature without his devotion and
> determination to see this through. Thanks a lot!
Thank you, Andrea!
Pip
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (3 preceding siblings ...)
2021-04-09 16:17 ` Pip Cet
@ 2021-04-09 16:35 ` Thierry Volpiatto
2021-04-09 18:57 ` Eli Zaretskii
2021-04-09 17:12 ` Jens C. Jensen
` (7 subsequent siblings)
12 siblings, 1 reply; 58+ messages in thread
From: Thierry Volpiatto @ 2021-04-09 16:35 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, Andrea Corallo
[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
> AFAICT, we are quite ready to land this important feature. The branch
> was tested on several systems and is in good shape: many issues and
> bugs were fixed, and currently no known issues remain that block the
> merge. (There's a lot yet to do wrt documenting the feature and its
> various aspects, but that can be done on master after merging.)
>
> If some of you have some unusual or rare or exotic system or Emacs
> configuration, and did not yet try building the native-comp branch,
> this is your chance to have a go before the merge: please build the
> branch and report any issues or problems you bump into.
I didn't have any answer about bug#46790, many things are broken for me
without fixing this...
> If no significant issues pop up within a week, I will ask Andrea to
> merge the branch onto master the next weekend (i.e. around 17th of
> April).
>
> Last, but not least: I'd like to take this opportunity to thank Andrea
> for his hard work and perseverance during this last year. We would
> not be where we are now with this feature without his devotion and
> determination to see this through. Thanks a lot!
--
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 16:35 ` Thierry Volpiatto
@ 2021-04-09 18:57 ` Eli Zaretskii
2021-04-10 5:39 ` Thierry Volpiatto
0 siblings, 1 reply; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-09 18:57 UTC (permalink / raw
To: Thierry Volpiatto; +Cc: emacs-devel, akrl
> From: Thierry Volpiatto <thievol@posteo.net>
> Cc: Andrea Corallo <akrl@sdf.org>, emacs-devel@gnu.org
> Date: Fri, 09 Apr 2021 18:35:48 +0200
>
> I didn't have any answer about bug#46790, many things are broken for me
> without fixing this...
I replied there now, and I hope that we will be able to come up with
some solution, although I'm a bit skeptical.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 18:57 ` Eli Zaretskii
@ 2021-04-10 5:39 ` Thierry Volpiatto
0 siblings, 0 replies; 58+ messages in thread
From: Thierry Volpiatto @ 2021-04-10 5:39 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, akrl
[-- Attachment #1: Type: text/plain, Size: 510 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Thierry Volpiatto <thievol@posteo.net>
>> Cc: Andrea Corallo <akrl@sdf.org>, emacs-devel@gnu.org
>> Date: Fri, 09 Apr 2021 18:35:48 +0200
>>
>> I didn't have any answer about bug#46790, many things are broken for me
>> without fixing this...
>
> I replied there now,
Thanks.
> and I hope that we will be able to come up with some solution,
> although I'm a bit skeptical.
I am sure you will, thanks to all for this feature.
--
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 686 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (4 preceding siblings ...)
2021-04-09 16:35 ` Thierry Volpiatto
@ 2021-04-09 17:12 ` Jens C. Jensen
2021-04-09 18:53 ` Stefan Monnier
2021-04-09 19:08 ` Andrea Corallo via Emacs development discussions.
2021-04-09 18:09 ` Sujith Manoharan
` (6 subsequent siblings)
12 siblings, 2 replies; 58+ messages in thread
From: Jens C. Jensen @ 2021-04-09 17:12 UTC (permalink / raw
To: Eli Zaretskii, emacs-devel; +Cc: Andrea Corallo
> From: Eli Zaretskii <eliz@gnu.org>
> Date: Fri, 09 Apr 2021 17:02:15 +0300
> Cc: Andrea Corallo <akrl@sdf.org>
> AFAICT, we are quite ready to land this important feature.
This is great news!
I've been on the branch for several months now with no major issues, the only oddity I've found was that natively-compiled elisp are subrs (as Pip already mentioned), which messed up my syntax highlighting.
A big Thank-You to Andrea for the great work getting this far!
P.S. Is Andreas website on gccemacs[1] the proper place to get in-depth information about the implementation? It feels more like a change-log.
[1] https://akrl.sdf.org/gccemacs.html
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 17:12 ` Jens C. Jensen
@ 2021-04-09 18:53 ` Stefan Monnier
2021-04-09 18:59 ` Jens C. Jensen
2021-04-09 19:08 ` Andrea Corallo via Emacs development discussions.
1 sibling, 1 reply; 58+ messages in thread
From: Stefan Monnier @ 2021-04-09 18:53 UTC (permalink / raw
To: Jens C. Jensen; +Cc: Eli Zaretskii, Andrea Corallo, emacs-devel
> I've been on the branch for several months now with no major issues, the
> only oddity I've found was that natively-compiled elisp are subrs (as Pip
> already mentioned), which messed up my syntax highlighting.
I'm curious: why would it affect syntax highlighting?
Stefan
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 18:53 ` Stefan Monnier
@ 2021-04-09 18:59 ` Jens C. Jensen
2021-04-09 22:43 ` Stefan Monnier
0 siblings, 1 reply; 58+ messages in thread
From: Jens C. Jensen @ 2021-04-09 18:59 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 09 Apr 2021 14:53:14 -0400
> I'm curious: why would it affect syntax highlighting?
I'm using `highlight-defined', which adds faces to defined variables/functions, I don't think it messes with any built-in highlighting.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 18:59 ` Jens C. Jensen
@ 2021-04-09 22:43 ` Stefan Monnier
2021-04-10 8:45 ` Jens C. Jensen
0 siblings, 1 reply; 58+ messages in thread
From: Stefan Monnier @ 2021-04-09 22:43 UTC (permalink / raw
To: Jens C. Jensen; +Cc: emacs-devel
>> I'm curious: why would it affect syntax highlighting?
> I'm using `highlight-defined', which adds faces to defined
> variables/functions, I don't think it messes with any
> built-in highlighting.
Still: why does `subrp` affect it?
Stefan
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 22:43 ` Stefan Monnier
@ 2021-04-10 8:45 ` Jens C. Jensen
2021-04-10 13:10 ` Stefan Monnier
0 siblings, 1 reply; 58+ messages in thread
From: Jens C. Jensen @ 2021-04-10 8:45 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 09 Apr 2021 18:43:59 -0400
> Cc: emacs-devel@gnu.org
>>> I'm curious: why would it affect syntax highlighting?
>> I'm using `highlight-defined', which adds faces to defined
>> variables/functions, I don't think it messes with any
>> built-in highlighting.
>
> Still: why does `subrp` affect it?
The problem seems to be the way `highlight-defined.el' determines if a function is built-in, using `(subrp (indirect-function #'some-function))'.
This evaluates to `nil' when an elisp function is defined or byte-compiled, but to `t' when it is native-compiled (or actually built-in).
The solution seems to be, like Andrea suggested, to test if a function is
`(and (subrp) (not (subr-native-elisp-p)))'.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-10 8:45 ` Jens C. Jensen
@ 2021-04-10 13:10 ` Stefan Monnier
0 siblings, 0 replies; 58+ messages in thread
From: Stefan Monnier @ 2021-04-10 13:10 UTC (permalink / raw
To: Jens C. Jensen; +Cc: emacs-devel
> The problem seems to be the way `highlight-defined.el' determines if
> a function is built-in, using `(subrp (indirect-function #'some-function))'.
Ah, so it purposefully decided to highlight "builtin" functions
differently. Not knowing why this is done (whether a function is
implemented in C or in ELisp is an implementation detail, which can
change from one version of Emacs to another), it's hard to know what
should happen with native-compiled functions.
Stefan
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 17:12 ` Jens C. Jensen
2021-04-09 18:53 ` Stefan Monnier
@ 2021-04-09 19:08 ` Andrea Corallo via Emacs development discussions.
2021-04-09 19:14 ` Eli Zaretskii
1 sibling, 1 reply; 58+ messages in thread
From: Andrea Corallo via Emacs development discussions. @ 2021-04-09 19:08 UTC (permalink / raw
To: Jens C. Jensen; +Cc: Eli Zaretskii, emacs-devel
"Jens C. Jensen" <jens@subst.net> writes:
>> From: Eli Zaretskii <eliz@gnu.org>
>> Date: Fri, 09 Apr 2021 17:02:15 +0300
>> Cc: Andrea Corallo <akrl@sdf.org>
>
>> AFAICT, we are quite ready to land this important feature.
>
> This is great news!
>
> I've been on the branch for several months now with no major issues,
> the only oddity I've found was that natively-compiled elisp are subrs
> (as Pip already mentioned), which messed up my syntax highlighting.
Hi Jens,
native compiled Lisp shares with primitives many aspects including for
instance calling conventions, OTOH this is just other native code we can
execute. Because of that felt natural to me to have these functions as
another kind of subr (also some of the internal implementation was
consequentially shared). IOW in the current implementation they are
really (slightly special) subrs.
I guess you have already figured that out but you can distinguish them
with `subr-native-elisp-p'.
> A big Thank-You to Andrea for the great work getting this far!
You are welcome :)
> P.S. Is Andreas website on gccemacs[1] the proper place to get in-depth information about the implementation? It feels more like a change-log.
>
>
> [1] https://akrl.sdf.org/gccemacs.html
Well, ATM as Eli mentioned, documentaiton is something a little lacking,
certanly in my dev blog some datastructure and mechanisms are
described/justified. Other than that you might want to have a look to:
<https://zenodo.org/record/3736363>
<https://toobnix.org/videos/watch/1f997b3c-00dc-4f7d-b2ce-74538c194fa7>
<https://toobnix.org/videos/watch/b985c5ca-fdcf-46ff-92d5-e68922fe4821>
ATM to go further I think the approach would be dumping passes and/or
starting to look into the source code. I tried my best to share with
the community what I was working on and how but is not the easiest when
the thing is being worked.
Thanks!
Andrea
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 19:08 ` Andrea Corallo via Emacs development discussions.
@ 2021-04-09 19:14 ` Eli Zaretskii
2021-04-10 0:07 ` Andy Moreton
0 siblings, 1 reply; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-09 19:14 UTC (permalink / raw
To: Andrea Corallo; +Cc: jens, emacs-devel
> From: Andrea Corallo <akrl@sdf.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Fri, 09 Apr 2021 19:08:17 +0000
>
> > P.S. Is Andreas website on gccemacs[1] the proper place to get in-depth information about the implementation? It feels more like a change-log.
> >
> >
> > [1] https://akrl.sdf.org/gccemacs.html
>
> Well, ATM as Eli mentioned, documentaiton is something a little lacking,
> certanly in my dev blog some datastructure and mechanisms are
> described/justified. Other than that you might want to have a look to:
>
> <https://zenodo.org/record/3736363>
> <https://toobnix.org/videos/watch/1f997b3c-00dc-4f7d-b2ce-74538c194fa7>
> <https://toobnix.org/videos/watch/b985c5ca-fdcf-46ff-92d5-e68922fe4821>
>
> ATM to go further I think the approach would be dumping passes and/or
> starting to look into the source code. I tried my best to share with
> the community what I was working on and how but is not the easiest when
> the thing is being worked.
I think it would be good to take the relevant parts of your blog and
rewrite them as introductory commentary to the code in comp.el, with
the goal of providing enough overview and background information to
let people discover the details by reading the code.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 19:14 ` Eli Zaretskii
@ 2021-04-10 0:07 ` Andy Moreton
2021-04-10 7:23 ` Eli Zaretskii
0 siblings, 1 reply; 58+ messages in thread
From: Andy Moreton @ 2021-04-10 0:07 UTC (permalink / raw
To: emacs-devel
On Fri 09 Apr 2021, Eli Zaretskii wrote:
>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> Date: Fri, 09 Apr 2021 19:08:17 +0000
>>
>> > P.S. Is Andreas website on gccemacs[1] the proper place to get in-depth
>> > information about the implementation? It feels more like a change-log.
>> >
>> >
>> > [1] https://akrl.sdf.org/gccemacs.html
>>
>> Well, ATM as Eli mentioned, documentaiton is something a little lacking,
>> certanly in my dev blog some datastructure and mechanisms are
>> described/justified. Other than that you might want to have a look to:
>>
>> <https://zenodo.org/record/3736363>
>> <https://toobnix.org/videos/watch/1f997b3c-00dc-4f7d-b2ce-74538c194fa7>
>> <https://toobnix.org/videos/watch/b985c5ca-fdcf-46ff-92d5-e68922fe4821>
>>
>> ATM to go further I think the approach would be dumping passes and/or
>> starting to look into the source code. I tried my best to share with
>> the community what I was working on and how but is not the easiest when
>> the thing is being worked.
>
> I think it would be good to take the relevant parts of your blog and
> rewrite them as introductory commentary to the code in comp.el, with
> the goal of providing enough overview and background information to
> let people discover the details by reading the code.
Perhaps some of this material could be added to the "GNU Emacs
Internals" section of the elisp manual.
AndyM
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-10 0:07 ` Andy Moreton
@ 2021-04-10 7:23 ` Eli Zaretskii
2021-04-10 11:40 ` Andy Moreton
0 siblings, 1 reply; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-10 7:23 UTC (permalink / raw
To: Andy Moreton; +Cc: emacs-devel
> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Sat, 10 Apr 2021 01:07:40 +0100
>
> >> <https://zenodo.org/record/3736363>
> >> <https://toobnix.org/videos/watch/1f997b3c-00dc-4f7d-b2ce-74538c194fa7>
> >> <https://toobnix.org/videos/watch/b985c5ca-fdcf-46ff-92d5-e68922fe4821>
> >>
> >> ATM to go further I think the approach would be dumping passes and/or
> >> starting to look into the source code. I tried my best to share with
> >> the community what I was working on and how but is not the easiest when
> >> the thing is being worked.
> >
> > I think it would be good to take the relevant parts of your blog and
> > rewrite them as introductory commentary to the code in comp.el, with
> > the goal of providing enough overview and background information to
> > let people discover the details by reading the code.
>
> Perhaps some of this material could be added to the "GNU Emacs
> Internals" section of the elisp manual.
Some of it, probably. But most of that stuff is inappropriate for the
manual. We have in several files large commentaries that provide
overview of the design and implementation of various features. For
example, the beginning of xdisp.c and coding.c, the overview of w32
subprocess support in w32proc.c, etc. I was thinking about a similar
overview in comp.el.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-10 7:23 ` Eli Zaretskii
@ 2021-04-10 11:40 ` Andy Moreton
0 siblings, 0 replies; 58+ messages in thread
From: Andy Moreton @ 2021-04-10 11:40 UTC (permalink / raw
To: emacs-devel
On Sat 10 Apr 2021, Eli Zaretskii wrote:
>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Sat, 10 Apr 2021 01:07:40 +0100
>>
>> >> <https://zenodo.org/record/3736363>
>> >> <https://toobnix.org/videos/watch/1f997b3c-00dc-4f7d-b2ce-74538c194fa7>
>> >> <https://toobnix.org/videos/watch/b985c5ca-fdcf-46ff-92d5-e68922fe4821>
>> >>
>> >> ATM to go further I think the approach would be dumping passes and/or
>> >> starting to look into the source code. I tried my best to share with
>> >> the community what I was working on and how but is not the easiest when
>> >> the thing is being worked.
>> >
>> > I think it would be good to take the relevant parts of your blog and
>> > rewrite them as introductory commentary to the code in comp.el, with
>> > the goal of providing enough overview and background information to
>> > let people discover the details by reading the code.
>>
>> Perhaps some of this material could be added to the "GNU Emacs
>> Internals" section of the elisp manual.
>
> Some of it, probably. But most of that stuff is inappropriate for the
> manual. We have in several files large commentaries that provide
> overview of the design and implementation of various features. For
> example, the beginning of xdisp.c and coding.c, the overview of w32
> subprocess support in w32proc.c, etc. I was thinking about a similar
> overview in comp.el.
Agreed: I expect that the lower level detail would go in comp.el and
a higher level overview in the manual.
AndyM
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (5 preceding siblings ...)
2021-04-09 17:12 ` Jens C. Jensen
@ 2021-04-09 18:09 ` Sujith Manoharan
2021-04-09 18:50 ` Eli Zaretskii
2021-04-09 18:27 ` Alex Bennée
` (5 subsequent siblings)
12 siblings, 1 reply; 58+ messages in thread
From: Sujith Manoharan @ 2021-04-09 18:09 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, Andrea Corallo
Eli Zaretskii <eliz@gnu.org> writes:
> If some of you have some unusual or rare or exotic system or Emacs
> configuration, and did not yet try building the native-comp branch,
> this is your chance to have a go before the merge: please build the
> branch and report any issues or problems you bump into.
Should users be concerned about the current situation in GCC ?
https://gcc.gnu.org/pipermail/gcc/2021-April/235340.html
The above thread has statements from several core developers that
paint a rather dire picture for a simple user like me - it looks
like GCC is imploding after the recent developments in the FSF.
As someone who kinda lives inside Emacs as far as computing
is concerned, I would like to use gccemacs, but GCC seems to
be heading toward some major disruptive event...
Sujith
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 18:09 ` Sujith Manoharan
@ 2021-04-09 18:50 ` Eli Zaretskii
0 siblings, 0 replies; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-09 18:50 UTC (permalink / raw
To: Sujith Manoharan; +Cc: emacs-devel, akrl
> From: Sujith Manoharan <sujith.oct@gmail.com>
> Cc: Andrea Corallo <akrl@sdf.org>, emacs-devel@gnu.org
> Date: Fri, 09 Apr 2021 23:39:36 +0530
>
> Should users be concerned about the current situation in GCC ?
>
> https://gcc.gnu.org/pipermail/gcc/2021-April/235340.html
That's something each user will have to decide for themselves.
libgccjit is a relatively immature part of GCC anyway (I mean relative
to the other components, like the C and C++ compilers), and no one
promises us that it will be maintained actively enough to not become a
problem in the future. What matters is that the current state of
libgccjit as of GCC 9 and up is "good enough" for our purposes.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (6 preceding siblings ...)
2021-04-09 18:09 ` Sujith Manoharan
@ 2021-04-09 18:27 ` Alex Bennée
2021-04-09 18:48 ` Andrea Corallo via Emacs development discussions.
` (4 subsequent siblings)
12 siblings, 0 replies; 58+ messages in thread
From: Alex Bennée @ 2021-04-09 18:27 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, Andrea Corallo
Eli Zaretskii <eliz@gnu.org> writes:
> AFAICT, we are quite ready to land this important feature. The branch
> was tested on several systems and is in good shape: many issues and
> bugs were fixed, and currently no known issues remain that block the
> merge. (There's a lot yet to do wrt documenting the feature and its
> various aspects, but that can be done on master after merging.)
>
> If some of you have some unusual or rare or exotic system or Emacs
> configuration, and did not yet try building the native-comp branch,
> this is your chance to have a go before the merge: please build the
> branch and report any issues or problems you bump into.
>
> If no significant issues pop up within a week, I will ask Andrea to
> merge the branch onto master the next weekend (i.e. around 17th of
> April).
>
> Last, but not least: I'd like to take this opportunity to thank Andrea
> for his hard work and perseverance during this last year. We would
> not be where we are now with this feature without his devotion and
> determination to see this through. Thanks a lot!
+1 - I've been running the native-comp branch as my daily work driver
for most of the last year. The few problems I've run into have been
quickly addressed by Andrea on the list so I'm perfectly happy it's
ready for a wider testing audience.
I'll switch my daily driver branch once merged ;-)
--
Alex Bennée
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (7 preceding siblings ...)
2021-04-09 18:27 ` Alex Bennée
@ 2021-04-09 18:48 ` Andrea Corallo via Emacs development discussions.
2021-04-14 4:39 ` Pankaj Jangid
` (3 subsequent siblings)
12 siblings, 0 replies; 58+ messages in thread
From: Andrea Corallo via Emacs development discussions. @ 2021-04-09 18:48 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> AFAICT, we are quite ready to land this important feature. The branch
> was tested on several systems and is in good shape: many issues and
> bugs were fixed, and currently no known issues remain that block the
> merge. (There's a lot yet to do wrt documenting the feature and its
> various aspects, but that can be done on master after merging.)
>
> If some of you have some unusual or rare or exotic system or Emacs
> configuration, and did not yet try building the native-comp branch,
> this is your chance to have a go before the merge: please build the
> branch and report any issues or problems you bump into.
>
> If no significant issues pop up within a week, I will ask Andrea to
> merge the branch onto master the next weekend (i.e. around 17th of
> April).
>
> Last, but not least: I'd like to take this opportunity to thank Andrea
> for his hard work and perseverance during this last year. We would
> not be where we are now with this feature without his devotion and
> determination to see this through. Thanks a lot!
Hi Eli,
having worked through this process with you all was an honor, but even
more was a pleasure :) I'm honestly very proud of being part of this
team.
I'm looking forward to keep on working on this to improve quality,
performance and functionality.
Thanks!
Andrea
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (8 preceding siblings ...)
2021-04-09 18:48 ` Andrea Corallo via Emacs development discussions.
@ 2021-04-14 4:39 ` Pankaj Jangid
2021-04-14 6:31 ` Eli Zaretskii
2021-04-14 9:45 ` Philip Kaludercic
` (2 subsequent siblings)
12 siblings, 1 reply; 58+ messages in thread
From: Pankaj Jangid @ 2021-04-14 4:39 UTC (permalink / raw
To: emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> AFAICT, we are quite ready to land this important feature. The branch
> was tested on several systems and is in good shape: many issues and
> bugs were fixed, and currently no known issues remain that block the
> merge. (There's a lot yet to do wrt documenting the feature and its
> various aspects, but that can be done on master after merging.)
I have started using Emacs from ‘native-comp’ branch last week. I am
doing this for the first time and following instructions from Andrea’s
gccemacs page.
I am on macos and after launching Emacs, I get this libgccjit
error. Is this something that I can ignore for now?
--8<---------------cut here---------------start------------->8---
Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging
Warning (comp): /Users/pankaj/Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp/cl-lib.el.gz: Error: Internal native compiler error failed to compile Disable showing Disable logging
--8<---------------cut here---------------end--------------->8---
Further, there are lots of compiler warnings from different package, as I
use Emacs. That means the native compilation is definitely working.
Other than this I haven’t noticed anything that could be a blocker. My
several packages, Gnus, everything is working fine.
--
Regards
Pankaj Jangid
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 4:39 ` Pankaj Jangid
@ 2021-04-14 6:31 ` Eli Zaretskii
0 siblings, 0 replies; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-14 6:31 UTC (permalink / raw
To: Pankaj Jangid; +Cc: emacs-devel
> From: Pankaj Jangid <pankaj@codeisgreat.org>
> Date: Wed, 14 Apr 2021 10:09:01 +0530
>
> I am on macos and after launching Emacs, I get this libgccjit
> error. Is this something that I can ignore for now?
>
> --8<---------------cut here---------------start------------->8---
> Warning (comp): libgccjit.so: error: error invoking gcc driver Disable showing Disable logging
> Warning (comp): /Users/pankaj/Applications/Emacs.app/Contents/Resources/lisp/emacs-lisp/cl-lib.el.gz: Error: Internal native compiler error failed to compile Disable showing Disable logging
> --8<---------------cut here---------------end--------------->8---
>
> Further, there are lots of compiler warnings from different package, as I
> use Emacs. That means the native compilation is definitely working.
Thanks for the feedback.
Please report this problem using report-emacs-bug, and mention
feature/native-comp in the Subject. When you do, please also tell
your version of GCC and libgccjit (you are using GCC, not clang that
disguises itself as GCC, right?).
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (9 preceding siblings ...)
2021-04-14 4:39 ` Pankaj Jangid
@ 2021-04-14 9:45 ` Philip Kaludercic
2021-04-14 10:14 ` Andrea Corallo via Emacs development discussions.
2021-04-14 15:53 ` wilde
2021-04-22 10:09 ` wilde
12 siblings, 1 reply; 58+ messages in thread
From: Philip Kaludercic @ 2021-04-14 9:45 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Andrea Corallo, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> If no significant issues pop up within a week, I will ask Andrea to
> merge the branch onto master the next weekend (i.e. around 17th of
> April).
I have been trying out the branch for the last few days and I didn't
notice any functional issues.
What was is annoying is the "sudden" warning buffers pop up, triggered
by from what I understand is the asynchronous (?) compilation. Is there
a way to mitigate this, and if so, it should be documented.
--
Philip K.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 9:45 ` Philip Kaludercic
@ 2021-04-14 10:14 ` Andrea Corallo via Emacs development discussions.
2021-04-14 10:35 ` Philip Kaludercic
0 siblings, 1 reply; 58+ messages in thread
From: Andrea Corallo via Emacs development discussions. @ 2021-04-14 10:14 UTC (permalink / raw
To: Philip Kaludercic; +Cc: Eli Zaretskii, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>> If no significant issues pop up within a week, I will ask Andrea to
>> merge the branch onto master the next weekend (i.e. around 17th of
>> April).
>
> I have been trying out the branch for the last few days and I didn't
> notice any functional issues.
>
> What was is annoying is the "sudden" warning buffers pop up, triggered
> by from what I understand is the asynchronous (?) compilation. Is there
> a way to mitigate this, and if so, it should be documented.
I Philip,
one can act on the `comp-async-report-warnings-errors' customize setting
it to nil (default is t).
Thanks
Andrea
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 10:14 ` Andrea Corallo via Emacs development discussions.
@ 2021-04-14 10:35 ` Philip Kaludercic
2021-04-14 10:45 ` Eli Zaretskii
2021-04-14 10:48 ` Andrea Corallo via Emacs development discussions.
0 siblings, 2 replies; 58+ messages in thread
From: Philip Kaludercic @ 2021-04-14 10:35 UTC (permalink / raw
To: Andrea Corallo; +Cc: Eli Zaretskii, emacs-devel
Andrea Corallo <akrl@sdf.org> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> If no significant issues pop up within a week, I will ask Andrea to
>>> merge the branch onto master the next weekend (i.e. around 17th of
>>> April).
>>
>> I have been trying out the branch for the last few days and I didn't
>> notice any functional issues.
>>
>> What was is annoying is the "sudden" warning buffers pop up, triggered
>> by from what I understand is the asynchronous (?) compilation. Is there
>> a way to mitigate this, and if so, it should be documented.
>
> I Philip,
>
> one can act on the `comp-async-report-warnings-errors' customize setting
> it to nil (default is t).
That should do it, thank you.
Does it make sense to have this enabled by default? At the very least,
ELPA packages should be addressed that trigger needless issues such as
overlong lines.
> Thanks
>
> Andrea
>
--
Philip K.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 10:35 ` Philip Kaludercic
@ 2021-04-14 10:45 ` Eli Zaretskii
2021-04-14 10:49 ` Eli Zaretskii
2021-04-14 12:57 ` Philip Kaludercic
2021-04-14 10:48 ` Andrea Corallo via Emacs development discussions.
1 sibling, 2 replies; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-14 10:45 UTC (permalink / raw
To: Philip Kaludercic; +Cc: emacs-devel, akrl
> From: Philip Kaludercic <philipk@posteo.net>
> Date: Wed, 14 Apr 2021 12:35:01 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>
> > one can act on the `comp-async-report-warnings-errors' customize setting
> > it to nil (default is t).
>
> That should do it, thank you.
>
> Does it make sense to have this enabled by default?
We decided not to do that, because these warnings point out to real
problems in the code, which just go unnoticed by the byte-compiler.
They should be fixed ASAP.
> At the very least, ELPA packages should be addressed that trigger
> needless issues such as overlong lines.
I don't understand how overlong lines are significant in this context,
please elaborate.
Thanks.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 10:45 ` Eli Zaretskii
@ 2021-04-14 10:49 ` Eli Zaretskii
2021-04-14 12:57 ` Philip Kaludercic
1 sibling, 0 replies; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-14 10:49 UTC (permalink / raw
To: philipk; +Cc: akrl, emacs-devel
> Date: Wed, 14 Apr 2021 13:45:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org, akrl@sdf.org
>
> > From: Philip Kaludercic <philipk@posteo.net>
> > Date: Wed, 14 Apr 2021 12:35:01 +0200
> > Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> >
> > > one can act on the `comp-async-report-warnings-errors' customize setting
> > > it to nil (default is t).
> >
> > That should do it, thank you.
> >
> > Does it make sense to have this enabled by default?
>
> We decided not to do that
Sorry, maybe you meant why it is enabled by default? In that case, we
decided that would be a good default for the reasons I explained in my
previous message.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 10:45 ` Eli Zaretskii
2021-04-14 10:49 ` Eli Zaretskii
@ 2021-04-14 12:57 ` Philip Kaludercic
2021-04-14 13:10 ` Eli Zaretskii
1 sibling, 1 reply; 58+ messages in thread
From: Philip Kaludercic @ 2021-04-14 12:57 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>> At the very least, ELPA packages should be addressed that trigger
>> needless issues such as overlong lines.
>
> I don't understand how overlong lines are significant in this context,
> please elaborate.
If I'm not mistaken, packages such as yasnippet generated warnings
(again, several minutes after Emacs itself was started) including more
or more or less trivial issues such as overlong lines.
--
Philip K.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 12:57 ` Philip Kaludercic
@ 2021-04-14 13:10 ` Eli Zaretskii
2021-04-14 14:00 ` Philip Kaludercic
0 siblings, 1 reply; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-14 13:10 UTC (permalink / raw
To: Philip Kaludercic; +Cc: emacs-devel, akrl
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: akrl@sdf.org, emacs-devel@gnu.org
> Date: Wed, 14 Apr 2021 14:57:44 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> At the very least, ELPA packages should be addressed that trigger
> >> needless issues such as overlong lines.
> >
> > I don't understand how overlong lines are significant in this context,
> > please elaborate.
>
> If I'm not mistaken, packages such as yasnippet generated warnings
> (again, several minutes after Emacs itself was started) including more
> or more or less trivial issues such as overlong lines.
Please show such a message, because I still don't think I understand,
perhaps because I don't know enough about yasnippet.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 13:10 ` Eli Zaretskii
@ 2021-04-14 14:00 ` Philip Kaludercic
2021-04-14 14:35 ` Stefan Kangas
2021-04-14 14:37 ` Eli Zaretskii
0 siblings, 2 replies; 58+ messages in thread
From: Philip Kaludercic @ 2021-04-14 14:00 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: akrl@sdf.org, emacs-devel@gnu.org
>> Date: Wed, 14 Apr 2021 14:57:44 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> At the very least, ELPA packages should be addressed that trigger
>> >> needless issues such as overlong lines.
>> >
>> > I don't understand how overlong lines are significant in this
>> > context,
>> > please elaborate.
>>
>> If I'm not mistaken, packages such as yasnippet generated warnings
>> (again, several minutes after Emacs itself was started) including
>> more
>> or more or less trivial issues such as overlong lines.
>
> Please show such a message, because I still don't think I understand,
> perhaps because I don't know enough about yasnippet.
From what I understand it is the regular compiler warning, just like you
would get without native-compile. So it is not related to yasnippet or
any other package itself. I tried it out, and in my case it looked like
this:
Compiling file /home/philip/.config/emacs/elpa/yasnippet-0.14.0/yasnippet.el at Wed Apr 14 15:57:58 2021
yasnippet.el:475:1: Warning: defvar `yas-after-exit-snippet-hook' docstring
wider than 80 characters
yasnippet.el:557:1: Warning: custom-declare-variable `yas-keymap-disable-hook'
docstring wider than 80 characters
The difference being that this is not generated when the package is
installed, but suddenly appears in a buffer.
--
Philip K.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 14:00 ` Philip Kaludercic
@ 2021-04-14 14:35 ` Stefan Kangas
2021-04-14 14:42 ` Philip Kaludercic
2021-04-14 14:50 ` Stefan Monnier
2021-04-14 14:37 ` Eli Zaretskii
1 sibling, 2 replies; 58+ messages in thread
From: Stefan Kangas @ 2021-04-14 14:35 UTC (permalink / raw
To: Philip Kaludercic, Eli Zaretskii; +Cc: akrl, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> From what I understand it is the regular compiler warning, just like you
> would get without native-compile. So it is not related to yasnippet or
> any other package itself. I tried it out, and in my case it looked like
> this:
>
> Compiling file /home/philip/.config/emacs/elpa/yasnippet-0.14.0/yasnippet.el at Wed Apr 14 15:57:58 2021
> yasnippet.el:475:1: Warning: defvar `yas-after-exit-snippet-hook' docstring
> wider than 80 characters
> yasnippet.el:557:1: Warning: custom-declare-variable `yas-keymap-disable-hook'
> docstring wider than 80 characters
These warnings should be fixed in yasnippet itself.
> The difference being that this is not generated when the package is
> installed, but suddenly appears in a buffer.
This shouldn't be a problem once we flip
`comp-async-report-warnings-errors' to nil by default. AFAIK, the plan
is to do that in time for Emacs 28. As others have explained, we keep
it set to t for now as it indicates real problems.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 14:35 ` Stefan Kangas
@ 2021-04-14 14:42 ` Philip Kaludercic
2021-04-14 14:50 ` Stefan Monnier
1 sibling, 0 replies; 58+ messages in thread
From: Philip Kaludercic @ 2021-04-14 14:42 UTC (permalink / raw
To: Stefan Kangas; +Cc: Eli Zaretskii, akrl, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Philip Kaludercic <philipk@posteo.net> writes:
>
>> From what I understand it is the regular compiler warning, just like you
>> would get without native-compile. So it is not related to yasnippet or
>> any other package itself. I tried it out, and in my case it looked like
>> this:
>>
>> Compiling file /home/philip/.config/emacs/elpa/yasnippet-0.14.0/yasnippet.el at Wed Apr 14 15:57:58 2021
>> yasnippet.el:475:1: Warning: defvar `yas-after-exit-snippet-hook' docstring
>> wider than 80 characters
>> yasnippet.el:557:1: Warning: custom-declare-variable `yas-keymap-disable-hook'
>> docstring wider than 80 characters
>
> These warnings should be fixed in yasnippet itself.
Of course.
>> The difference being that this is not generated when the package is
>> installed, but suddenly appears in a buffer.
>
> This shouldn't be a problem once we flip
> `comp-async-report-warnings-errors' to nil by default. AFAIK, the plan
> is to do that in time for Emacs 28. As others have explained, we keep
> it set to t for now as it indicates real problems.
Good to hear, that certainly sounds sensible.
--
Philip K.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 14:35 ` Stefan Kangas
2021-04-14 14:42 ` Philip Kaludercic
@ 2021-04-14 14:50 ` Stefan Monnier
2021-04-14 15:02 ` Eli Zaretskii
1 sibling, 1 reply; 58+ messages in thread
From: Stefan Monnier @ 2021-04-14 14:50 UTC (permalink / raw
To: Stefan Kangas; +Cc: Philip Kaludercic, emacs-devel, Eli Zaretskii, akrl
>> The difference being that this is not generated when the package is
>> installed, but suddenly appears in a buffer.
>
> This shouldn't be a problem once we flip
> `comp-async-report-warnings-errors' to nil by default. AFAIK, the plan
> is to do that in time for Emacs 28. As others have explained, we keep
> it set to t for now as it indicates real problems.
The warnings mentioned in this thread are those we normally see when we
byte-compile the file, which should be a separate step from the async
compilation to native code, so AFAICT showing those warnings during
native compilation is not very useful (what would be useful would be
warnings/info specific to async/native compilation).
Stefan
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 14:50 ` Stefan Monnier
@ 2021-04-14 15:02 ` Eli Zaretskii
0 siblings, 0 replies; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-14 15:02 UTC (permalink / raw
To: Stefan Monnier; +Cc: philipk, emacs-devel, stefan, akrl
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Philip Kaludercic <philipk@posteo.net>, Eli Zaretskii <eliz@gnu.org>,
> akrl@sdf.org, emacs-devel@gnu.org
> Date: Wed, 14 Apr 2021 10:50:45 -0400
>
> >> The difference being that this is not generated when the package is
> >> installed, but suddenly appears in a buffer.
> >
> > This shouldn't be a problem once we flip
> > `comp-async-report-warnings-errors' to nil by default. AFAIK, the plan
> > is to do that in time for Emacs 28. As others have explained, we keep
> > it set to t for now as it indicates real problems.
>
> The warnings mentioned in this thread are those we normally see when we
> byte-compile the file, which should be a separate step from the async
> compilation to native code, so AFAICT showing those warnings during
> native compilation is not very useful
They are useful because native compilation frequently flags issues
that byte compilation doesn't (because the former happens in a more
pristine environment than the latter).
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 14:00 ` Philip Kaludercic
2021-04-14 14:35 ` Stefan Kangas
@ 2021-04-14 14:37 ` Eli Zaretskii
2021-04-14 14:48 ` Dmitry Gutov
1 sibling, 1 reply; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-14 14:37 UTC (permalink / raw
To: Philip Kaludercic; +Cc: emacs-devel, akrl
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: akrl@sdf.org, emacs-devel@gnu.org
> Date: Wed, 14 Apr 2021 16:00:46 +0200
>
> >> If I'm not mistaken, packages such as yasnippet generated warnings
> >> (again, several minutes after Emacs itself was started) including
> >> more
> >> or more or less trivial issues such as overlong lines.
> >
> > Please show such a message, because I still don't think I understand,
> > perhaps because I don't know enough about yasnippet.
>
> >From what I understand it is the regular compiler warning, just like you
> would get without native-compile. So it is not related to yasnippet or
> any other package itself. I tried it out, and in my case it looked like
> this:
>
> Compiling file /home/philip/.config/emacs/elpa/yasnippet-0.14.0/yasnippet.el at Wed Apr 14 15:57:58 2021
> yasnippet.el:475:1: Warning: defvar `yas-after-exit-snippet-hook' docstring
> wider than 80 characters
> yasnippet.el:557:1: Warning: custom-declare-variable `yas-keymap-disable-hook'
> docstring wider than 80 characters
Ah, overlong lines in _docstrings_... Yes, that's known, but why not
fix this issue in the first place? I get the same warning when
byte-compiling with Emacs 28, so this is not new with the
native-compile branch.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 14:37 ` Eli Zaretskii
@ 2021-04-14 14:48 ` Dmitry Gutov
2021-04-14 17:10 ` Eli Zaretskii
0 siblings, 1 reply; 58+ messages in thread
From: Dmitry Gutov @ 2021-04-14 14:48 UTC (permalink / raw
To: Eli Zaretskii, Philip Kaludercic; +Cc: akrl, emacs-devel
On 14.04.2021 17:37, Eli Zaretskii wrote:
> Ah, overlong lines in_docstrings_... Yes, that's known, but why not
> fix this issue in the first place? I get the same warning when
> byte-compiling with Emacs 28, so this is not new with the
> native-compile branch.
I guess the issue is that native compilation happens after the package
is installed, so the warnings come basically out of the blue.
If installed packages were native-compiled during the installation
process, it would be less surprising. Though of course there are
downsides to that approach as well.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 14:48 ` Dmitry Gutov
@ 2021-04-14 17:10 ` Eli Zaretskii
0 siblings, 0 replies; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-14 17:10 UTC (permalink / raw
To: Dmitry Gutov; +Cc: philipk, emacs-devel, akrl
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Wed, 14 Apr 2021 17:48:11 +0300
> Cc: akrl@sdf.org, emacs-devel@gnu.org
>
> On 14.04.2021 17:37, Eli Zaretskii wrote:
> > Ah, overlong lines in_docstrings_... Yes, that's known, but why not
> > fix this issue in the first place? I get the same warning when
> > byte-compiling with Emacs 28, so this is not new with the
> > native-compile branch.
>
> I guess the issue is that native compilation happens after the package
> is installed, so the warnings come basically out of the blue.
I was originally annoyed by this, but eventually concluded that it's
all part of the automatic background compilation, something we didn't
have before. I think with time people will get used to it, and the
surprise will go away. And if someone is really annoyed, they can
always disable automatic background compilation altogether.
I tend to think that turning warnings off is not a good idea, for the
same reasons we don't by default turn off byte-compilation warnings.
But we will cross this bridge when we come to it.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 10:35 ` Philip Kaludercic
2021-04-14 10:45 ` Eli Zaretskii
@ 2021-04-14 10:48 ` Andrea Corallo via Emacs development discussions.
1 sibling, 0 replies; 58+ messages in thread
From: Andrea Corallo via Emacs development discussions. @ 2021-04-14 10:48 UTC (permalink / raw
To: Philip Kaludercic; +Cc: Eli Zaretskii, emacs-devel
Philip Kaludercic <philipk@posteo.net> writes:
> Andrea Corallo <akrl@sdf.org> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> If no significant issues pop up within a week, I will ask Andrea to
>>>> merge the branch onto master the next weekend (i.e. around 17th of
>>>> April).
>>>
>>> I have been trying out the branch for the last few days and I didn't
>>> notice any functional issues.
>>>
>>> What was is annoying is the "sudden" warning buffers pop up, triggered
>>> by from what I understand is the asynchronous (?) compilation. Is there
>>> a way to mitigate this, and if so, it should be documented.
>>
>> I Philip,
>>
>> one can act on the `comp-async-report-warnings-errors' customize setting
>> it to nil (default is t).
>
> That should do it, thank you.
>
> Does it make sense to have this enabled by default? At the very least,
> ELPA packages should be addressed that trigger needless issues such as
> overlong lines.
I think this was discussed a while ago here around and the consensus was
"for now" to keep it t as default so developers can come to know and
address issues, for the future I guess likely is going changed.
Andrea
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (10 preceding siblings ...)
2021-04-14 9:45 ` Philip Kaludercic
@ 2021-04-14 15:53 ` wilde
2021-04-14 17:02 ` Eli Zaretskii
2021-04-22 10:09 ` wilde
12 siblings, 1 reply; 58+ messages in thread
From: wilde @ 2021-04-14 15:53 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Andrea Corallo, emacs-devel
Eli Zaretskii <eliz@gnu.org> wrote:
> If some of you have some unusual or rare or exotic system or Emacs
> configuration, and did not yet try building the native-comp branch,
> this is your chance to have a go before the merge: please build the
> branch and report any issues or problems you bump into.
Today I build and started using Emacs from the on a small i368 system
with NetBSD 9.1:
System spec:
CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
RAM: 2 GiB
Build:
- I build libgccjit from gcc 10.2.0 manually as libgccjit seems not to
be available from pkgsrc (not checked very thoroughly though) at least
I found no `pkgin' installable binaries...
- I had to manually remove `-ldl' from LIBGCCJIT in src/Makefile as this
is not needed on *BSD (and triggers an error during build, when
present)
IMO, this should be fixed in configure.ac (The same problem might
exist for --with-modules, in case it is supported on *BSD, didn't test
though...)
- I hat to disable memory protection on the system to make the native
compiler work:
sysctl -w security.pax.mprotect.global=0
sysctl -w security.pax.mprotect.enabled=0
This is not a Emacs specific problem but a problem with libgccjit
itself. (The basic gcc jit "Hello World" example also fails with
memory protection in place).
The native compiling Emacs itself seems to run fine (I'm right now
writing this message in gnus on the said system) and the performance
improvement is very noticeable on this small system. Thanks a LOT to
Andrea for this major improvement of GNU Emacs!
cheers
sascha
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 15:53 ` wilde
@ 2021-04-14 17:02 ` Eli Zaretskii
2021-04-14 17:28 ` Alex Bennée
` (2 more replies)
0 siblings, 3 replies; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-14 17:02 UTC (permalink / raw
To: wilde; +Cc: akrl, emacs-devel
> From: wilde@sha-bang.de
> Cc: emacs-devel@gnu.org, Andrea Corallo <akrl@sdf.org>
> Date: Wed, 14 Apr 2021 17:53:33 +0200
>
> Today I build and started using Emacs from the on a small i368 system
> with NetBSD 9.1:
>
> System spec:
> CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
> RAM: 2 GiB
>
> Build:
> - I build libgccjit from gcc 10.2.0 manually as libgccjit seems not to
> be available from pkgsrc (not checked very thoroughly though) at least
> I found no `pkgin' installable binaries...
>
> - I had to manually remove `-ldl' from LIBGCCJIT in src/Makefile as this
> is not needed on *BSD (and triggers an error during build, when
> present)
Andrea, looks like NetBSD is in the same boat as OpenBSD, where we
already refrain from using -ldl.
> - I hat to disable memory protection on the system to make the native
> compiler work:
> sysctl -w security.pax.mprotect.global=0
> sysctl -w security.pax.mprotect.enabled=0
> This is not a Emacs specific problem but a problem with libgccjit
> itself. (The basic gcc jit "Hello World" example also fails with
> memory protection in place).
I'm not sure I understand why this happens, but I think this issue
should be reported to the GCC Bugzilla.
> The native compiling Emacs itself seems to run fine (I'm right now
> writing this message in gnus on the said system) and the performance
> improvement is very noticeable on this small system. Thanks a LOT to
> Andrea for this major improvement of GNU Emacs!
Thanks for testing the branch.
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 17:02 ` Eli Zaretskii
@ 2021-04-14 17:28 ` Alex Bennée
2021-04-14 17:41 ` Eli Zaretskii
2021-04-14 18:07 ` Andrea Corallo via Emacs development discussions.
2021-04-15 11:19 ` wilde
2 siblings, 1 reply; 58+ messages in thread
From: Alex Bennée @ 2021-04-14 17:28 UTC (permalink / raw
To: Eli Zaretskii; +Cc: wilde, emacs-devel, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>> From: wilde@sha-bang.de
>> Cc: emacs-devel@gnu.org, Andrea Corallo <akrl@sdf.org>
>> Date: Wed, 14 Apr 2021 17:53:33 +0200
>>
>> Today I build and started using Emacs from the on a small i368 system
>> with NetBSD 9.1:
>>
>> System spec:
>> CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
>> RAM: 2 GiB
>>
>> Build:
>> - I build libgccjit from gcc 10.2.0 manually as libgccjit seems not to
>> be available from pkgsrc (not checked very thoroughly though) at least
>> I found no `pkgin' installable binaries...
>>
>> - I had to manually remove `-ldl' from LIBGCCJIT in src/Makefile as this
>> is not needed on *BSD (and triggers an error during build, when
>> present)
>
> Andrea, looks like NetBSD is in the same boat as OpenBSD, where we
> already refrain from using -ldl.
>
>> - I hat to disable memory protection on the system to make the native
>> compiler work:
>> sysctl -w security.pax.mprotect.global=0
>> sysctl -w security.pax.mprotect.enabled=0
>> This is not a Emacs specific problem but a problem with libgccjit
>> itself. (The basic gcc jit "Hello World" example also fails with
>> memory protection in place).
>
> I'm not sure I understand why this happens, but I think this issue
> should be reported to the GCC Bugzilla.
I suspect this is a change similar to the recent MacOS one where
eXecutable pages cannot be mapped as Writable. The QEMU project recently
had to implement split mappings for it's JIT to workaround this although
I dare say there is probably a JIT interface that should be used to give
suitable access to pages but that is something for the BSD experts to
chime in on.
--
Alex Bennée
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 17:28 ` Alex Bennée
@ 2021-04-14 17:41 ` Eli Zaretskii
2021-04-15 11:15 ` Alex Bennée
0 siblings, 1 reply; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-14 17:41 UTC (permalink / raw
To: Alex Bennée; +Cc: wilde, emacs-devel, akrl
> From: Alex Bennée <alex.bennee@linaro.org>
> Cc: wilde@sha-bang.de, akrl@sdf.org, emacs-devel@gnu.org
> Date: Wed, 14 Apr 2021 18:28:49 +0100
>
> >> sysctl -w security.pax.mprotect.global=0
> >> sysctl -w security.pax.mprotect.enabled=0
> >> This is not a Emacs specific problem but a problem with libgccjit
> >> itself. (The basic gcc jit "Hello World" example also fails with
> >> memory protection in place).
> >
> > I'm not sure I understand why this happens, but I think this issue
> > should be reported to the GCC Bugzilla.
>
> I suspect this is a change similar to the recent MacOS one where
> eXecutable pages cannot be mapped as Writable. The QEMU project recently
> had to implement split mappings for it's JIT to workaround this although
> I dare say there is probably a JIT interface that should be used to give
> suitable access to pages but that is something for the BSD experts to
> chime in on.
Are you sure this is relevant? libgccjit, contrary to its name, is
not JIT code production, at least in Emacs. It produces a file, a
shared library which is later loaded. Why does this have to need
executable memory pages?
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 17:41 ` Eli Zaretskii
@ 2021-04-15 11:15 ` Alex Bennée
0 siblings, 0 replies; 58+ messages in thread
From: Alex Bennée @ 2021-04-15 11:15 UTC (permalink / raw
To: Eli Zaretskii; +Cc: wilde, emacs-devel, akrl
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Alex Bennée <alex.bennee@linaro.org>
>> Cc: wilde@sha-bang.de, akrl@sdf.org, emacs-devel@gnu.org
>> Date: Wed, 14 Apr 2021 18:28:49 +0100
>>
>> >> sysctl -w security.pax.mprotect.global=0
>> >> sysctl -w security.pax.mprotect.enabled=0
>> >> This is not a Emacs specific problem but a problem with libgccjit
>> >> itself. (The basic gcc jit "Hello World" example also fails with
>> >> memory protection in place).
>> >
>> > I'm not sure I understand why this happens, but I think this issue
>> > should be reported to the GCC Bugzilla.
>>
>> I suspect this is a change similar to the recent MacOS one where
>> eXecutable pages cannot be mapped as Writable. The QEMU project recently
>> had to implement split mappings for it's JIT to workaround this although
>> I dare say there is probably a JIT interface that should be used to give
>> suitable access to pages but that is something for the BSD experts to
>> chime in on.
>
> Are you sure this is relevant?
Not entirely - it was an educated guess but the write up in the BSD
pages seems to indicate this behaviour:
PaX MPROTECT
PaX MPROTECT implements memory protection restrictions, meant to comple-
ment non-executable mappings. The purpose is to prevent situations where
malicious code attempts to mark writable memory regions as executable,
often by trashing arguments to an mprotect(2) call.
While it can be enabled globally, NetBSD provides a tool, paxctl(8), to
enable PaX MPROTECT on a per-program basis.
Example usage:
# paxctl +M /usr/sbin/sshd
Enabling PaX MPROTECT globally:
# sysctl -w security.pax.mprotect.global=1
PaX MPROTECT affects the following three uses:
· Processes that utilize code generation (such as the JVM) might
need to have MPROTECT disabled.
· Miscompiled programs that have text relocations, will now core
dump instead of having their relocations corrected. You will
need to fix those programs (recompile them properly).
· Debugger breakpoints: gdb(1) needs to be able to write to the
text segment in order to insert and delete breakpoints. This
will not work unless MPROTECT is disabled on the executable.
> libgccjit, contrary to its name, is not JIT code production, at least
> in Emacs. It produces a file, a shared library which is later loaded.
> Why does this have to need executable memory pages?
Well any page with code needs to executable. The question is how does
libgccjit handle it? Does it write a stream of bytes to a file that is
then mapped in r-x to be executed or does it map a file -w- to write the
instruction stream and then just remap it afterwards r-x when it's
"loaded". If it's ultimately the same page changes permissions I can
expect the above would complain.
I'm not familiar enough with how libgccjit generates and loads the code.
--
Alex Bennée
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 17:02 ` Eli Zaretskii
2021-04-14 17:28 ` Alex Bennée
@ 2021-04-14 18:07 ` Andrea Corallo via Emacs development discussions.
2021-04-14 20:23 ` Stefan Kangas
2021-04-15 11:19 ` wilde
2 siblings, 1 reply; 58+ messages in thread
From: Andrea Corallo via Emacs development discussions. @ 2021-04-14 18:07 UTC (permalink / raw
To: Eli Zaretskii; +Cc: wilde, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: wilde@sha-bang.de
>> Cc: emacs-devel@gnu.org, Andrea Corallo <akrl@sdf.org>
>> Date: Wed, 14 Apr 2021 17:53:33 +0200
>>
>> Today I build and started using Emacs from the on a small i368 system
>> with NetBSD 9.1:
>>
>> System spec:
>> CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
>> RAM: 2 GiB
>>
>> Build:
>> - I build libgccjit from gcc 10.2.0 manually as libgccjit seems not to
>> be available from pkgsrc (not checked very thoroughly though) at least
>> I found no `pkgin' installable binaries...
>>
>> - I had to manually remove `-ldl' from LIBGCCJIT in src/Makefile as this
>> is not needed on *BSD (and triggers an error during build, when
>> present)
>
> Andrea, looks like NetBSD is in the same boat as OpenBSD, where we
> already refrain from using -ldl.
Right thanks for the hint, bfaa6df492 should do the job; Sascha please
have a try.
Andrea
PS thanks also for fixing 0c1fc9d581
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 18:07 ` Andrea Corallo via Emacs development discussions.
@ 2021-04-14 20:23 ` Stefan Kangas
2021-04-14 22:01 ` Andrea Corallo via Emacs development discussions.
0 siblings, 1 reply; 58+ messages in thread
From: Stefan Kangas @ 2021-04-14 20:23 UTC (permalink / raw
To: Andrea Corallo, Eli Zaretskii; +Cc: wilde, emacs-devel
Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: wilde@sha-bang.de
>>> Cc: emacs-devel@gnu.org, Andrea Corallo <akrl@sdf.org>
>>> Date: Wed, 14 Apr 2021 17:53:33 +0200
>>>
>>> Today I build and started using Emacs from the on a small i368 system
>>> with NetBSD 9.1:
>>>
>>> System spec:
>>> CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
>>> RAM: 2 GiB
>>>
>>> Build:
>>> - I build libgccjit from gcc 10.2.0 manually as libgccjit seems not to
>>> be available from pkgsrc (not checked very thoroughly though) at least
>>> I found no `pkgin' installable binaries...
>>>
>>> - I had to manually remove `-ldl' from LIBGCCJIT in src/Makefile as this
>>> is not needed on *BSD (and triggers an error during build, when
>>> present)
>>
>> Andrea, looks like NetBSD is in the same boat as OpenBSD, where we
>> already refrain from using -ldl.
>
> Right thanks for the hint, bfaa6df492 should do the job; Sascha please
> have a try.
The above seems to be talking about NetBSD, but bfaa6df492 adds
"freebsd" to configure.ac. Is that expected?
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 20:23 ` Stefan Kangas
@ 2021-04-14 22:01 ` Andrea Corallo via Emacs development discussions.
2021-04-15 9:25 ` wilde
0 siblings, 1 reply; 58+ messages in thread
From: Andrea Corallo via Emacs development discussions. @ 2021-04-14 22:01 UTC (permalink / raw
To: Stefan Kangas; +Cc: Eli Zaretskii, wilde, emacs-devel
Stefan Kangas <stefankangas@gmail.com> writes:
> Andrea Corallo via "Emacs development discussions."
> <emacs-devel@gnu.org> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: wilde@sha-bang.de
>>>> Cc: emacs-devel@gnu.org, Andrea Corallo <akrl@sdf.org>
>>>> Date: Wed, 14 Apr 2021 17:53:33 +0200
>>>>
>>>> Today I build and started using Emacs from the on a small i368 system
>>>> with NetBSD 9.1:
>>>>
>>>> System spec:
>>>> CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz
>>>> RAM: 2 GiB
>>>>
>>>> Build:
>>>> - I build libgccjit from gcc 10.2.0 manually as libgccjit seems not to
>>>> be available from pkgsrc (not checked very thoroughly though) at least
>>>> I found no `pkgin' installable binaries...
>>>>
>>>> - I had to manually remove `-ldl' from LIBGCCJIT in src/Makefile as this
>>>> is not needed on *BSD (and triggers an error during build, when
>>>> present)
>>>
>>> Andrea, looks like NetBSD is in the same boat as OpenBSD, where we
>>> already refrain from using -ldl.
>>
>> Right thanks for the hint, bfaa6df492 should do the job; Sascha please
>> have a try.
>
> The above seems to be talking about NetBSD, but bfaa6df492 adds
> "freebsd" to configure.ac. Is that expected?
No it's not, 686259e65a should do better, thanks for catching!
Andrea
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 22:01 ` Andrea Corallo via Emacs development discussions.
@ 2021-04-15 9:25 ` wilde
0 siblings, 0 replies; 58+ messages in thread
From: wilde @ 2021-04-15 9:25 UTC (permalink / raw
To: Andrea Corallo via Emacs development discussions.
Cc: Eli Zaretskii, Stefan Kangas, Andrea Corallo
Andrea Corallo via "Emacs development discussions." <emacs-devel@gnu.org> wrote:
> Stefan Kangas <stefankangas@gmail.com> writes:
>> Andrea Corallo via "Emacs development discussions."
>> <emacs-devel@gnu.org> writes:
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: wilde@sha-bang.de
>>>>> Date: Wed, 14 Apr 2021 17:53:33 +0200
>>>>>
>>>>> Today I build and started using Emacs from the on a small i368 system
>>>>> with NetBSD 9.1:
>>>>> - I had to manually remove `-ldl' from LIBGCCJIT in src/Makefile as this
>>>>> is not needed on *BSD (and triggers an error during build, when
>>>>> present)
>>>>
>>>> Andrea, looks like NetBSD is in the same boat as OpenBSD, where we
>>>> already refrain from using -ldl.
>>>
>>> Right thanks for the hint, bfaa6df492 should do the job; Sascha please
>>> have a try.
>>
>> The above seems to be talking about NetBSD, but bfaa6df492 adds
>> "freebsd" to configure.ac. Is that expected?
>
> No it's not, 686259e65a should do better, thanks for catching!
I can confirm, that the branch now builds without manual changes to the
Makefile on NetBSD. Thanks!
As side note: it seems you reverted the change for freebsd, my
understanding is that the libc of all *BSD is rather similar in this
respect, therefor I'd expect the change to be needed for freebsd as
well. :)
cheers
sascha
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-14 17:02 ` Eli Zaretskii
2021-04-14 17:28 ` Alex Bennée
2021-04-14 18:07 ` Andrea Corallo via Emacs development discussions.
@ 2021-04-15 11:19 ` wilde
2021-04-15 16:23 ` Andrea Corallo via Emacs development discussions.
2021-04-27 16:25 ` wilde
2 siblings, 2 replies; 58+ messages in thread
From: wilde @ 2021-04-15 11:19 UTC (permalink / raw
To: Eli Zaretskii; +Cc: akrl, emacs-devel
Eli Zaretskii <eliz@gnu.org> wrote:
>> - I hat to disable memory protection on the system to make the native
>> compiler work:
>> sysctl -w security.pax.mprotect.global=0
>> sysctl -w security.pax.mprotect.enabled=0
>> This is not a Emacs specific problem but a problem with libgccjit
>> itself. (The basic gcc jit "Hello World" example also fails with
>> memory protection in place).
>
> I'm not sure I understand why this happens, but I think this issue
> should be reported to the GCC Bugzilla.
It turns out, that disabling security.pax.mprotect.global is enough,
however this still poses a potential security risk and means that
libgccjit can not be used on default setup of NetBSD.
I created a upstream report:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096
cheers
sascha
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-15 11:19 ` wilde
@ 2021-04-15 16:23 ` Andrea Corallo via Emacs development discussions.
2021-04-27 16:25 ` wilde
1 sibling, 0 replies; 58+ messages in thread
From: Andrea Corallo via Emacs development discussions. @ 2021-04-15 16:23 UTC (permalink / raw
To: wilde; +Cc: Eli Zaretskii, emacs-devel
wilde@sha-bang.de writes:
> Eli Zaretskii <eliz@gnu.org> wrote:
>>> - I hat to disable memory protection on the system to make the native
>>> compiler work:
>>> sysctl -w security.pax.mprotect.global=0
>>> sysctl -w security.pax.mprotect.enabled=0
>>> This is not a Emacs specific problem but a problem with libgccjit
>>> itself. (The basic gcc jit "Hello World" example also fails with
>>> memory protection in place).
>>
>> I'm not sure I understand why this happens, but I think this issue
>> should be reported to the GCC Bugzilla.
>
> It turns out, that disabling security.pax.mprotect.global is enough,
> however this still poses a potential security risk and means that
> libgccjit can not be used on default setup of NetBSD.
>
> I created a upstream report:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096
Thanks
Andrea
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-15 11:19 ` wilde
2021-04-15 16:23 ` Andrea Corallo via Emacs development discussions.
@ 2021-04-27 16:25 ` wilde
2021-04-28 3:06 ` Corwin Brust
2021-04-28 17:52 ` Jose E. Marchesi
1 sibling, 2 replies; 58+ messages in thread
From: wilde @ 2021-04-27 16:25 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel, akrl
wilde@sha-bang.de wrote:
>>> - I hat to disable memory protection on the system to make the native
>>> compiler work:
[...]
> I created a upstream report:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096
Just in case someone else stumbles across this thread: the upstream bug
has been resolved and should be fixed in subsequent releases of gcc.
(Its even cherry picked for the gcc 10 release branch)
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-27 16:25 ` wilde
@ 2021-04-28 3:06 ` Corwin Brust
2021-04-28 17:52 ` Jose E. Marchesi
1 sibling, 0 replies; 58+ messages in thread
From: Corwin Brust @ 2021-04-28 3:06 UTC (permalink / raw
To: wilde; +Cc: Eli Zaretskii, Andrea Corallo, Emacs developers
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
\o/
On Tue, Apr 27, 2021 at 11:26 AM <wilde@sha-bang.de> wrote:
> wilde@sha-bang.de wrote:
> >>> - I hat to disable memory protection on the system to make the native
> >>> compiler work:
> [...]
> > I created a upstream report:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096
>
> Just in case someone else stumbles across this thread: the upstream bug
> has been resolved and should be fixed in subsequent releases of gcc.
> (Its even cherry picked for the gcc 10 release branch)
>
>
Congratulations and thank you!
In a similar vein, for the benefit of those who may find it useful later:
The below linked thread celebrates the completed merge of "gccmacs" (the
ability for Emacs to transform elisp into "native" compilation units) into
master for release (probably) with Emacs 28 (dates TBD or IDK ;)
https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg01175.html
--
*Corwin*
612-217-1742
612-695-4276 (signal)
*corwin@bru.st <corwin@bru.st>*
[-- Attachment #2: Type: text/html, Size: 2411 bytes --]
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-27 16:25 ` wilde
2021-04-28 3:06 ` Corwin Brust
@ 2021-04-28 17:52 ` Jose E. Marchesi
2021-04-29 8:20 ` Arthur Miller
1 sibling, 1 reply; 58+ messages in thread
From: Jose E. Marchesi @ 2021-04-28 17:52 UTC (permalink / raw
To: wilde; +Cc: Eli Zaretskii, emacs-devel, akrl
> wilde@sha-bang.de wrote:
>>>> - I hat to disable memory protection on the system to make the native
>>>> compiler work:
> [...]
>> I created a upstream report:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096
>
> Just in case someone else stumbles across this thread: the upstream bug
> has been resolved and should be fixed in subsequent releases of gcc.
> (Its even cherry picked for the gcc 10 release branch)
This is very exciting news.
Congratulations for the great work! :)
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-28 17:52 ` Jose E. Marchesi
@ 2021-04-29 8:20 ` Arthur Miller
0 siblings, 0 replies; 58+ messages in thread
From: Arthur Miller @ 2021-04-29 8:20 UTC (permalink / raw
To: Jose E. Marchesi; +Cc: wilde, Eli Zaretskii, akrl, emacs-devel
"Jose E. Marchesi" <jemarch@gnu.org> writes:
>> wilde@sha-bang.de wrote:
>>>>> - I hat to disable memory protection on the system to make the native
>>>>> compiler work:
>> [...]
>>> I created a upstream report:
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100096
>>
>> Just in case someone else stumbles across this thread: the upstream bug
>> has been resolved and should be fixed in subsequent releases of gcc.
>> (Its even cherry picked for the gcc 10 release branch)
>
> This is very exciting news.
> Congratulations for the great work! :)
Indeed, congrats from me too. Thanks to Andrea, Eli and all of you who
worked hard to make this possible! <3
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-09 14:02 Getting ready to land native-compilation on master Eli Zaretskii
` (11 preceding siblings ...)
2021-04-14 15:53 ` wilde
@ 2021-04-22 10:09 ` wilde
2021-04-22 11:14 ` Eli Zaretskii
12 siblings, 1 reply; 58+ messages in thread
From: wilde @ 2021-04-22 10:09 UTC (permalink / raw
To: Eli Zaretskii; +Cc: Andrea Corallo, emacs-devel
Hi Eli,
Eli Zaretskii <eliz@gnu.org> wrote:
> AFAICT, we are quite ready to land this important feature.
[…]
> If no significant issues pop up within a week, I will ask Andrea to
> merge the branch onto master the next weekend (i.e. around 17th of
> April).
As this did not happen yet I assume that significant bugs, blocking the
merge, did pop up (one of which might have been the PATH related issues
I was also experiencing and testing).
Please forgive my ignorance, but is there a place where the progress on
the merge and the list of blocking issues are tracked?
I don't want to be a nuisance, but I'm really looking forward to this
great feature being merged into master... :)
cheers
sascha
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: Getting ready to land native-compilation on master
2021-04-22 10:09 ` wilde
@ 2021-04-22 11:14 ` Eli Zaretskii
0 siblings, 0 replies; 58+ messages in thread
From: Eli Zaretskii @ 2021-04-22 11:14 UTC (permalink / raw
To: wilde; +Cc: akrl, emacs-devel
> From: wilde@sha-bang.de
> Cc: emacs-devel@gnu.org, Andrea Corallo <akrl@sdf.org>
> Date: Thu, 22 Apr 2021 12:09:38 +0200
>
> Hi Eli,
>
> Eli Zaretskii <eliz@gnu.org> wrote:
> > AFAICT, we are quite ready to land this important feature.
> […]
> > If no significant issues pop up within a week, I will ask Andrea to
> > merge the branch onto master the next weekend (i.e. around 17th of
> > April).
>
> As this did not happen yet I assume that significant bugs, blocking the
> merge, did pop up (one of which might have been the PATH related issues
> I was also experiencing and testing).
No blocking bugs are known at this point, we just delayed the merge
due to the issue with symlinks. If no new problems are reported, I
will ask Andrea to merge this coming weekend.
^ permalink raw reply [flat|nested] 58+ messages in thread