From: Eli Zaretskii <eliz@gnu.org>
To: akrl@sdf.org
Cc: larsi@gnus.org, monnier@iro.umontreal.ca, 43725@debbugs.gnu.org
Subject: bug#43725: 28.0.50; Include feature/native-comp into master
Date: Sat, 13 Feb 2021 22:06:51 +0200 [thread overview]
Message-ID: <831rdjd95w.fsf@gnu.org> (raw)
In-Reply-To: <83v9drp8va.fsf@gnu.org> (message from Eli Zaretskii on Fri, 27 Nov 2020 09:16:41 +0200)
Andrea, can you please explain why there are so many changes in Lisp
files on the branch?
For example, what are changes like this one about:
+(declare-function subr-native-lambda-list "data.c")
Or this:
+ ((and (featurep 'nativecomp)
+ (subrp def)
+ (listp (subr-native-lambda-list def)))
+ (subr-native-lambda-list def))
Or this:
+ ;; Never native compile to allow cc-defs.el:2345 hack.
+ (declare (speed -1))
This will not work on MS-Windows, you need to use path-separator to do
it portably:
+ (when (featurep 'nativecomp)
+ (defvar comp-eln-load-path)
+ (let ((path-env (getenv "EMACSNATIVELOADPATH")))
+ (when path-env
+ (dolist (path (split-string path-env ":")) <<<<<<<<<<<<<
+ (unless (string= "" path)
+ (push path comp-eln-load-path)))))
+ (push (concat user-emacs-directory "eln-cache/") comp-eln-load-path))
I'm not sure I understand this addition to epaths.nt:
+/* Like PATH_LOADSEARCH, but contains the relative path from the
+ installation directory.
+*/
+#define PATH_REL_LOADSEARCH ""
Can you explain how PATH_REL_LOADSEARCH is supposed to work, and for
what purpose it was introduced?
A few minor comments about the C code:
This is unsafe, because a fixnum can be larger than PTRDIFF_MAX:
+static gcc_jit_lvalue *
+emit_mvar_lval (Lisp_Object mvar)
+{
+ Lisp_Object mvar_slot = CALL1I (comp-mvar-slot, mvar);
+
+ if (EQ (mvar_slot, Qscratch))
+ {
+ if (!comp.scratch)
+ comp.scratch = gcc_jit_function_new_local (comp.func,
+ NULL,
+ comp.lisp_obj_type,
+ "scratch");
+ return comp.scratch;
+ }
+
+ return comp.frame[XFIXNUM (mvar_slot)]; <<<<<<<<<<<<<<<<<<<<
+}
Likewise, this is unsafe because a fixnum can be larger than INT_MAX:
+ if (!FIXNUMP (idx))
+ xsignal1 (Qnative_ice,
+ build_string ("inconsistent data relocation container"));
+ reloc.idx = gcc_jit_context_new_rvalue_from_int (comp.ctxt,
+ comp.ptrdiff_type,
+ XFIXNUM (idx)); <<<<<<<<
(There are several more calls with the same problem.)
Several comparisons like this one:
+ if (val != (long) val)
are IMO better written as
if (val > LONG_MAX || val < LONG_MIN)
Here, wouldn't it be better to have an assertion that there are no
more than 6 elements in the list:
+ Lisp_Object arg[6];
+
+ Lisp_Object p = XCDR (insn);
+ ptrdiff_t i = 0;
+ FOR_EACH_TAIL (p)
+ {
+ if (i == sizeof (arg) / sizeof (Lisp_Object))
+ break;
+ arg[i++] = XCAR (p);
+ }
If there are more than 6, we will be writing beyond the end of the
arg[] array.
This is nonportable:
+ if (!noninteractive)
+ {
+ sigset_t blocked;
+ /* Gcc doesn't like being interrupted at all. */
+ block_input ();
+ sigemptyset (&blocked);
+ sigaddset (&blocked, SIGALRM);
+ sigaddset (&blocked, SIGINT);
+#ifdef USABLE_SIGIO
+ sigaddset (&blocked, SIGIO);
+#endif
+ pthread_sigmask (SIG_BLOCK, &blocked, &saved_sigset); <<<<<<<<<<<
+ count = SPECPDL_INDEX ();
+ record_unwind_protect_void (restore_sigmask);
+ }
We shouldn't use pthread_sigmask unconditionally, we should use it
only on Posix platforms. Can you explain why the signals here should
be blocked? What happens if they aren't, and a signal arrives while
the compilation runs? I'm asking because on MS-Windows blocking
signals with sigaddset/sigmask doesn't really work, so the question is
what if anything should be done here on Windows.
Here, 'i' could be ptrdiff_t, no need to use EMACS_INT:
+ EMACS_INT d_vec_len = XFIXNUM (Flength (comp_u->data_vec));
+ for (EMACS_INT i = 0; i < d_vec_len; i++)
+ if (!EQ (data_relocs[i], AREF (comp_u->data_vec, i)))
+ return false;
+
+ d_vec_len = XFIXNUM (Flength (comp_u->data_impure_vec));
+ for (EMACS_INT i = 0; i < d_vec_len; i++)
This should have a big FIXME, since it means the name of the DLL is in
two different places, and if we need to support a differently-named
DLL, we are in trouble:
+#ifdef WINDOWSNT
+ /* We may need to load libgccjit when dumping before term/w32-win.el
+ defines `dynamic-library-alist`. This will fail if that variable
+ is empty, so add libgccjit-0.dll to it. */
+ if (will_dump_p ())
+ Vdynamic_library_alist = list1 (list2 (Qgccjit,
+ build_string ("libgccjit-0.dll")));
Is there a more elegant way of resolving this difficulty?
This lacks the ENCODE_FILE part:
+ char *fname = SSDATA (concat2 (Vinvocation_directory,
+ XCAR (comp_u->file)));
+ FILE *file;
+ if ((file = fopen (fname, "r")))
And why are you using fopen instead of emacs_fopen?
next prev parent reply other threads:[~2021-02-13 20:06 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-30 15:44 bug#43725: 28.0.50; Include feature/native-comp into master Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-09-30 17:27 ` Lars Ingebrigtsen
2020-09-30 22:37 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-01 1:34 ` Lars Ingebrigtsen
2020-10-01 7:51 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-01 13:13 ` Eli Zaretskii
2020-10-01 13:40 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-01 15:55 ` Lars Ingebrigtsen
2020-10-01 2:40 ` Eli Zaretskii
2020-10-02 19:39 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-02 19:46 ` Eli Zaretskii
2020-10-02 19:58 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-03 7:27 ` Eli Zaretskii
2020-10-03 17:23 ` Lars Ingebrigtsen
2020-10-03 18:40 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-06 16:39 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-07 4:28 ` Lars Ingebrigtsen
2020-10-07 14:47 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-10-09 4:20 ` Lars Ingebrigtsen
2020-10-06 17:11 ` Stefan Monnier
2020-11-25 18:35 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-26 10:10 ` Lars Ingebrigtsen
2020-11-26 11:19 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-26 11:28 ` Lars Ingebrigtsen
2020-11-26 12:02 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-12-04 22:28 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-12-06 13:13 ` Lars Ingebrigtsen
2020-11-26 14:17 ` Eli Zaretskii
2020-11-26 21:15 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2020-11-27 7:16 ` Eli Zaretskii
2021-02-13 20:06 ` Eli Zaretskii [this message]
2021-02-14 20:22 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-16 21:13 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-17 15:18 ` Eli Zaretskii
2021-02-18 21:22 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-19 8:08 ` Eli Zaretskii
2021-02-18 20:32 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-18 20:36 ` Eli Zaretskii
2021-02-18 20:53 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-19 7:51 ` Eli Zaretskii
2021-02-19 11:13 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-19 12:23 ` Eli Zaretskii
2021-02-19 22:03 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-20 6:57 ` Eli Zaretskii
2021-02-19 12:53 ` Pip Cet
2021-02-19 13:37 ` Eli Zaretskii
2021-02-19 14:16 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-19 14:23 ` Pip Cet
2021-02-19 14:35 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-19 14:59 ` Eli Zaretskii
2021-02-19 15:00 ` Pip Cet
2021-02-19 15:11 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-19 17:33 ` Andy Moreton
2021-02-18 21:56 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-19 8:14 ` Eli Zaretskii
2021-02-18 21:58 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-19 8:16 ` Eli Zaretskii
2021-02-22 20:08 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-02-22 20:51 ` Pip Cet
2021-02-23 3:23 ` Eli Zaretskii
2021-02-26 19:31 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-09 19:13 ` Eli Zaretskii
2021-03-09 19:28 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-09 19:53 ` Eli Zaretskii
2021-03-09 20:09 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-10 13:13 ` Eli Zaretskii
2021-03-10 13:16 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-10 15:09 ` Eli Zaretskii
2021-03-10 15:45 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-10 16:33 ` Eli Zaretskii
2021-03-10 16:45 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-10 17:06 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-14 17:22 ` Eli Zaretskii
2021-03-14 19:06 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-14 19:51 ` Eli Zaretskii
2021-03-14 20:00 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-15 15:19 ` Eli Zaretskii
2021-03-15 15:43 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-15 18:33 ` Eli Zaretskii
2021-03-15 20:00 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-20 11:00 ` Eli Zaretskii
2021-03-20 11:55 ` Eli Zaretskii
2021-03-21 8:32 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-03-21 9:57 ` Eli Zaretskii
2021-03-15 14:57 ` Eli Zaretskii
2021-05-01 18:24 ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-01 19:06 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831rdjd95w.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=43725@debbugs.gnu.org \
--cc=akrl@sdf.org \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).