From debbugs-submit-bounces@debbugs.gnu.org Sun Oct 23 08:13:10 2022 Received: (at submit) by debbugs.gnu.org; 23 Oct 2022 12:13:10 +0000 Received: from localhost ([127.0.0.1]:43803 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1omZqo-0005TN-Ef for submit@debbugs.gnu.org; Sun, 23 Oct 2022 08:13:10 -0400 Received: from lists.gnu.org ([209.51.188.17]:50268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1omZql-0005TF-SR for submit@debbugs.gnu.org; Sun, 23 Oct 2022 08:13:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omZql-0006Y9-7d for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2022 08:13:07 -0400 Received: from mx3.muc.de ([193.149.48.5]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1omZqj-0007oY-2T for bug-gnu-emacs@gnu.org; Sun, 23 Oct 2022 08:13:06 -0400 Received: (qmail 58759 invoked by uid 3782); 23 Oct 2022 14:12:49 +0200 Received: from acm.muc.de (p2e5d5154.dip0.t-ipconnect.de [46.93.81.84]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 23 Oct 2022 14:12:49 +0200 Received: (qmail 24445 invoked by uid 1000); 23 Oct 2022 12:12:49 -0000 Date: Sun, 23 Oct 2022 12:12:49 +0000 To: bug-gnu-emacs@gnu.org Subject: Lack of error message about number of args (?native compilation?) Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.5; envelope-from=acm@muc.de; helo=mx3.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) Hello, Emacs. Firstly, note that the function desktop-buffer has exactly 12 parameters. With an up to date Emacs 29: (i) emacs -Q (ii) M-x load-library RET desktop RET. (iii) M-x disassemble RET desktop-buffer. Note that this is native code. (iv) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET This gives an error message about 4 not being a list. What it ought to do is instead throw an error about the number of arguments. This is a bug. (v) M-x load-file RET /path/to/emacs/lisp/desktop.elc. (vi) M-x disassemble RET desktop-buffer. Note that we now have byte compiled code. (vii) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET We now get a correct error message about the numbere of arguments. As a matter of interest, I noticed this bug while byte-compiling desktop.el inside Emacs. It gave a warning message about the number of parameters to desktop-buffer having changed from 12+ to 12. Here, I suspect there's a bug in the native compilation of desktop-buffer. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 24 12:41:43 2022 Received: (at 58739) by debbugs.gnu.org; 24 Oct 2022 16:41:43 +0000 Received: from localhost ([127.0.0.1]:49354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1on0WE-0003SK-Vs for submit@debbugs.gnu.org; Mon, 24 Oct 2022 12:41:43 -0400 Received: from mx3.muc.de ([193.149.48.5]:46527) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1on0WC-0003Rs-G0 for 58739@debbugs.gnu.org; Mon, 24 Oct 2022 12:41:42 -0400 Received: (qmail 59395 invoked by uid 3782); 24 Oct 2022 18:41:26 +0200 Received: from acm.muc.de (p4fe15cdd.dip0.t-ipconnect.de [79.225.92.221]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 24 Oct 2022 18:41:25 +0200 Received: (qmail 6569 invoked by uid 1000); 24 Oct 2022 16:41:25 -0000 Date: Mon, 24 Oct 2022 16:41:25 +0000 To: Andrea Corallo Subject: Re: bug#58739: Lack of error message about number of args (?native compilation?) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58739 Cc: 58739@debbugs.gnu.org, acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Andrea. On Sun, Oct 23, 2022 at 12:12:49 +0000, Alan Mackenzie wrote: > Hello, Emacs. > Firstly, note that the function desktop-buffer has exactly 12 > parameters. > With an up to date Emacs 29: > (i) emacs -Q > (ii) M-x load-library RET desktop RET. > (iii) M-x disassemble RET desktop-buffer. > Note that this is native code. > (iv) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET > This gives an error message about 4 not being a list. What it ought to > do is instead throw an error about the number of arguments. This is a > bug. > (v) M-x load-file RET /path/to/emacs/lisp/desktop.elc. > (vi) M-x disassemble RET desktop-buffer. > Note that we now have byte compiled code. > (vii) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET > We now get a correct error message about the numbere of arguments. > As a matter of interest, I noticed this bug while byte-compiling > desktop.el inside Emacs. It gave a warning message about the number of > parameters to desktop-buffer having changed from 12+ to 12. > Here, I suspect there's a bug in the native compilation of > desktop-buffer. The problem here is that (func-arity 'desktop-buffer) returns (12 . 12) on a byte compiled desktop.elc, but (12 . many) on the corresponding .eln file. This (12 . many) must be regarded as a bug, since there are no &rest parameters in desktop-buffer. I propose a minor amendment to the definition of MANY, such that it will mean "there are &rest parameters", rather than "the calling convention is with nargs + *args". I have implemented this, and my patch is below. What I want to ask you to check is that in the native compiler, when declare_imported_func encounters a function with, say, exactly 12 arguments, it will throw an error. I think this is actually correct, since the compiler cannot know whether this function uses the subr calling convention of nargs + *args, or the byte coded convention of pushing the 12 arguments individually onto the stack. Is throwing this error a good idea? Thanks! Here's my proposed patch: Amend the meaning of "MANY"; this solves bug #58739 Make "MANY" mean there are &rest parameters. The previous definition left ambiguous whether a subr with over 8 parameters also had &rest parameters. * lisp/emacs-lisp/comp.el (comp-prepare-args-for-top-level): Return the number of parameters rather than `many' when this is a fixed number over 8. * src/comp.c (declare_imported_func): Throw an error when an imported function has a fixed number over 8 of parameters, since we cannot compile a call to this which will work for both byte code and native code. * src/eval.c (eval_sub, funcall_subr): Where we test for MANY, also test the number of arguments against 8. (funcall_subr): Resolve the previous inability to call subr's with a fixed number over 8 of arguments. diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el index 5a05fe4854..f7e118616d 100644 --- a/lisp/emacs-lisp/comp.el +++ b/lisp/emacs-lisp/comp.el @@ -2057,9 +2057,10 @@ comp-prepare-args-for-top-level "Lexically-scoped FUNCTION." (let ((args (comp-func-l-args function))) (cons (make-comp-mvar :constant (comp-args-base-min args)) - (make-comp-mvar :constant (if (comp-args-p args) - (comp-args-max args) - 'many))))) + (make-comp-mvar :constant (cond + ((comp-args-p args) (comp-args-max args)) + ((comp-nargs-rest args) 'many) + (t (comp-nargs-nonrest args))))))) (cl-defmethod comp-prepare-args-for-top-level ((function comp-func-d)) "Dynamically scoped FUNCTION." diff --git a/src/comp.c b/src/comp.c index 14012634cc..8c9db20e72 100644 --- a/src/comp.c +++ b/src/comp.c @@ -999,6 +999,13 @@ declare_imported_func (Lisp_Object subr_sym, gcc_jit_type *ret_type, types = SAFE_ALLOCA (nargs * sizeof (* types)); types[0] = comp.lisp_obj_type; } + else if (nargs > 8) + /* The calling convention for a function with a fixed number of + arguments greater than eight is different between a native + compiled function and a byte compiled function. Thus we + cannot safely compile it with the native compiler. */ + signal_error ("Imported function has too many arguments safely to compile natively", + subr_sym); else if (!types) { types = SAFE_ALLOCA (nargs * sizeof (* types)); diff --git a/src/eval.c b/src/eval.c index 8810136c04..495dbb53b5 100644 --- a/src/eval.c +++ b/src/eval.c @@ -2433,7 +2433,9 @@ eval_sub (Lisp_Object form) else if (XSUBR (fun)->max_args == UNEVALLED) val = (XSUBR (fun)->function.aUNEVALLED) (args_left); - else if (XSUBR (fun)->max_args == MANY) + else if (XSUBR (fun)->max_args == MANY + || XSUBR (fun)->max_args > 8) + { /* Pass a vector of evaluated arguments. */ Lisp_Object *vals; @@ -2996,7 +2998,8 @@ funcall_subr (struct Lisp_Subr *subr, ptrdiff_t numargs, Lisp_Object *args) if (numargs >= subr->min_args) { /* Conforming call to finite-arity subr. */ - if (numargs <= subr->max_args) + if (numargs <= subr->max_args + && subr->max_args <= 8) { Lisp_Object argbuf[8]; Lisp_Object *a; @@ -3032,15 +3035,13 @@ funcall_subr (struct Lisp_Subr *subr, ptrdiff_t numargs, Lisp_Object *args) return subr->function.a8 (a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7]); default: - /* If a subr takes more than 8 arguments without using MANY - or UNEVALLED, we need to extend this function to support it. - Until this is done, there is no way to call the function. */ - emacs_abort (); + emacs_abort (); /* Can't happen. */ } } /* Call to n-adic subr. */ - if (subr->max_args == MANY) + if (subr->max_args == MANY + || subr->max_args > 8) return subr->function.aMANY (numargs, args); } diff --git a/src/lisp.h b/src/lisp.h index 5f6721595c..881548ead4 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3187,10 +3187,11 @@ CHECK_SUBR (Lisp_Object x) `minargs' should be a number, the minimum number of arguments allowed. `maxargs' should be a number, the maximum number of arguments allowed, or else MANY or UNEVALLED. - MANY means pass a vector of evaluated arguments, - in the form of an integer number-of-arguments - followed by the address of a vector of Lisp_Objects - which contains the argument values. + MANY means there are &rest arguments. Here we pass a vector + of evaluated arguments in the form of an integer + number-of-arguments followed by the address of a vector of + Lisp_Objects which contains the argument values. (We also use + this convention when calling a subr with more than 8 parameters.) UNEVALLED means pass the list of unevaluated arguments `intspec' says how interactive arguments are to be fetched. If the string starts with a `(', `intspec' is evaluated and the resulting -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Oct 25 16:15:44 2022 Received: (at 58739) by debbugs.gnu.org; 25 Oct 2022 20:15:44 +0000 Received: from localhost ([127.0.0.1]:52483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onQKt-0005Lw-Hf for submit@debbugs.gnu.org; Tue, 25 Oct 2022 16:15:43 -0400 Received: from mx.sdf.org ([205.166.94.24]:56426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1onQKr-0005Lm-3O for 58739@debbugs.gnu.org; Tue, 25 Oct 2022 16:15:41 -0400 Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 29PKFcWI019884 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 25 Oct 2022 20:15:38 GMT From: Andrea Corallo To: Alan Mackenzie Subject: Re: bug#58739: Lack of error message about number of args (?native compilation?) In-Reply-To: (Alan Mackenzie's message of "Mon, 24 Oct 2022 16:41:25 +0000") References: Date: Tue, 25 Oct 2022 20:15:38 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58739 Cc: 58739@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > Hello, Andrea. > > On Sun, Oct 23, 2022 at 12:12:49 +0000, Alan Mackenzie wrote: >> Hello, Emacs. > >> Firstly, note that the function desktop-buffer has exactly 12 >> parameters. > >> With an up to date Emacs 29: > >> (i) emacs -Q >> (ii) M-x load-library RET desktop RET. >> (iii) M-x disassemble RET desktop-buffer. > >> Note that this is native code. > >> (iv) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET > >> This gives an error message about 4 not being a list. What it ought to >> do is instead throw an error about the number of arguments. This is a >> bug. > >> (v) M-x load-file RET /path/to/emacs/lisp/desktop.elc. >> (vi) M-x disassemble RET desktop-buffer. > >> Note that we now have byte compiled code. > >> (vii) M-: (desktop-buffer 1 2 3 4 5 6 7 8 9 10 11 12 13) RET > >> We now get a correct error message about the numbere of arguments. > >> As a matter of interest, I noticed this bug while byte-compiling >> desktop.el inside Emacs. It gave a warning message about the number of >> parameters to desktop-buffer having changed from 12+ to 12. > >> Here, I suspect there's a bug in the native compilation of >> desktop-buffer. > > The problem here is that (func-arity 'desktop-buffer) returns (12 . 12) on a > byte compiled desktop.elc, but (12 . many) on the corresponding .eln file. > This (12 . many) must be regarded as a bug, since there are no &rest > parameters in desktop-buffer. > > I propose a minor amendment to the definition of MANY, such that it will > mean "there are &rest parameters", rather than "the calling convention > is with nargs + *args". I have implemented this, and my patch is below. > > What I want to ask you to check is that in the native compiler, when > declare_imported_func encounters a function with, say, exactly 12 > arguments, it will throw an error. I think this is actually correct, > since the compiler cannot know whether this function uses the subr > calling convention of nargs + *args, or the byte coded convention of > pushing the 12 arguments individually onto the stack. Is throwing this > error a good idea? Hi Alan, to me this fix looks like a good idea (assuming changing the definition of MANY is acceptable). I think also that throwing the error in 'declare_imported_func' is okay at this point. Just two small nits (forgive me please :) : > Thanks! > > Here's my proposed patch: [...] > } > + else if (nargs > 8) > + /* The calling convention for a function with a fixed number of > + arguments greater than eight is different between a native ^^^ I think this should be aligned with the initial 'The' > + compiled function and a byte compiled function. Thus we > + cannot safely compile it with the native compiler. */ > + signal_error ("Imported function has too many arguments safely to compile natively", I think we should break this string to stay within 78 characters (see CONTRIBUTE). > + subr_sym); > else if (!types) > { > types = SAFE_ALLOCA (nargs * sizeof (* types)); > diff --git a/src/eval.c b/src/eval.c > index 8810136c04..495dbb53b5 100644 > --- a/src/eval.c > +++ b/src/eval.c > @@ -2433,7 +2433,9 @@ eval_sub (Lisp_Object form) > > else if (XSUBR (fun)->max_args == UNEVALLED) > val = (XSUBR (fun)->function.aUNEVALLED) (args_left); > - else if (XSUBR (fun)->max_args == MANY) > + else if (XSUBR (fun)->max_args == MANY > + || XSUBR (fun)->max_args > 8) > + > { > /* Pass a vector of evaluated arguments. */ > Lisp_Object *vals; > @@ -2996,7 +2998,8 @@ funcall_subr (struct Lisp_Subr *subr, ptrdiff_t numargs, Lisp_Object *args) Likewise > if (numargs >= subr->min_args) > { > /* Conforming call to finite-arity subr. */ > - if (numargs <= subr->max_args) > + if (numargs <= subr->max_args > + && subr->max_args <= 8) > { > Lisp_Object argbuf[8]; > Lisp_Object *a; > @@ -3032,15 +3035,13 @@ funcall_subr (struct Lisp_Subr *subr, ptrdiff_t numargs, Lisp_Object *args) Likewise > return subr->function.a8 (a[0], a[1], a[2], a[3], a[4], a[5], > a[6], a[7]); [...] Thanks for the patch! Andrea From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 29 08:04:51 2022 Received: (at 58739) by debbugs.gnu.org; 29 Oct 2022 12:04:51 +0000 Received: from localhost ([127.0.0.1]:35083 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ooka2-00079X-W5 for submit@debbugs.gnu.org; Sat, 29 Oct 2022 08:04:51 -0400 Received: from mx3.muc.de ([193.149.48.5]:38546) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ookZy-00079G-WB for 58739@debbugs.gnu.org; Sat, 29 Oct 2022 08:04:49 -0400 Received: (qmail 350 invoked by uid 3782); 29 Oct 2022 14:04:40 +0200 Received: from acm.muc.de (p4fe15996.dip0.t-ipconnect.de [79.225.89.150]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 Oct 2022 14:04:40 +0200 Received: (qmail 7489 invoked by uid 1000); 29 Oct 2022 12:04:36 -0000 Date: Sat, 29 Oct 2022 12:04:36 +0000 To: Andrea Corallo Subject: Re: bug#58739: Lack of error message about number of args (?native compilation?) Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58739 Cc: 58739@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Hello, Andrea. On Tue, Oct 25, 2022 at 20:15:38 +0000, Andrea Corallo wrote: > Alan Mackenzie writes: > > On Sun, Oct 23, 2022 at 12:12:49 +0000, Alan Mackenzie wrote: [ .... ] > >> As a matter of interest, I noticed this bug while byte-compiling > >> desktop.el inside Emacs. It gave a warning message about the number of > >> parameters to desktop-buffer having changed from 12+ to 12. > >> Here, I suspect there's a bug in the native compilation of > >> desktop-buffer. > > The problem here is that (func-arity 'desktop-buffer) returns (12 . 12) on a > > byte compiled desktop.elc, but (12 . many) on the corresponding .eln file. > > This (12 . many) must be regarded as a bug, since there are no &rest > > parameters in desktop-buffer. > > I propose a minor amendment to the definition of MANY, such that it will > > mean "there are &rest parameters", rather than "the calling convention > > is with nargs + *args". I have implemented this, and my patch is below. > > What I want to ask you to check is that in the native compiler, when > > declare_imported_func encounters a function with, say, exactly 12 > > arguments, it will throw an error. I think this is actually correct, > > since the compiler cannot know whether this function uses the subr > > calling convention of nargs + *args, or the byte coded convention of > > pushing the 12 arguments individually onto the stack. Is throwing this > > error a good idea? > Hi Alan, > to me this fix looks like a good idea (assuming changing the definition > of MANY is acceptable). We'll see what Eli says. > I think also that throwing the error in 'declare_imported_func' is okay > at this point. Apologies at this point. I should have produced an error from this before bothering you. I was unable to produce such an error, and I've spent the last few days understanding what happens here, with this result: A call from a native compiled function is always in the form nargs + *args, regardless of whether there are more than 8 arguments or not. More accurately, the call to an unknown type of function (.eln/.elc/.el) puts the function (in some form, I don't know exactly what) at element 0 of *args, and the arguments themselves starting at element 1 of *args. It then calls Ffuncall (or something like it). When the called function is a byte-code function, further down the call stack exec_byte_code gets called with this (nargs + 1) + *args. exec_byte_code then pushes the arguments onto the stack before interpreting the byte code. So this "problem" with the native compiler not knowing what call sequence to generate isn't a problem at all. It's all dealt with at run time. No doubt this slows down Emacs quite a bit, but it's safe. So I'll take that bit out of my patch, and commit the rest of it to master, and see what happens from there. > Just two small nits (forgive me please :) : Thanks for these, I've incorporated them into my amended source code. [ .... ] > Thanks for the patch! > Andrea -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 29 08:48:45 2022 Received: (at 58739) by debbugs.gnu.org; 29 Oct 2022 12:48:45 +0000 Received: from localhost ([127.0.0.1]:35126 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oolGX-0008I5-6F for submit@debbugs.gnu.org; Sat, 29 Oct 2022 08:48:45 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oolGU-0008Hs-J8 for 58739@debbugs.gnu.org; Sat, 29 Oct 2022 08:48:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oolGO-0005Ve-SW; Sat, 29 Oct 2022 08:48:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8semC6wMvLq/t/WFPvJfV0a0Jsv8cLjxzMx3Lbrl9C0=; b=htaLzyh8A/Sz n9CegjNjgHZUkYAIdvosLTry8DuuwSTP0t/Nw1wxpFi83NztCi6ytVCxpBnWsh/T3nY4RbhOqUBLW qWT152SV4cKDwtzDLqTpkMN3R5WfIeKeIlDMY6EOIid0jcr7CI8jn71M5bswxZMSxuzK1bSHOjnvL S0sNGohNsNoJ2bs5ChaHuXUGFhElgw1kZTNxwjCk1evehKDNrRjOCLvdUQumK8i+GbIh0VuRokAYe BoWv23/cIKAMNm2zMaer4e1RoBoAemGDSl1DESCFn3kpfj9/KCjs6EhXxJcaJdBAdW3Ig0Z4BWB66 PbbgnZWi8oQWbYbwN/H3iA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oolGO-0001CD-Bl; Sat, 29 Oct 2022 08:48:36 -0400 Date: Sat, 29 Oct 2022 15:48:35 +0300 Message-Id: <831qqqiyn0.fsf@gnu.org> From: Eli Zaretskii To: Alan Mackenzie In-Reply-To: (message from Alan Mackenzie on Sat, 29 Oct 2022 12:04:36 +0000) Subject: Re: bug#58739: Lack of error message about number of args (?native compilation?) References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 58739 Cc: 58739@debbugs.gnu.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 58739@debbugs.gnu.org > Date: Sat, 29 Oct 2022 12:04:36 +0000 > From: Alan Mackenzie > > > to me this fix looks like a good idea (assuming changing the definition > > of MANY is acceptable). > > We'll see what Eli says. About what, may I ask? From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 29 09:32:26 2022 Received: (at 58739-done) by debbugs.gnu.org; 29 Oct 2022 13:32:26 +0000 Received: from localhost ([127.0.0.1]:35162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oolwo-0000vo-8z for submit@debbugs.gnu.org; Sat, 29 Oct 2022 09:32:26 -0400 Received: from mx3.muc.de ([193.149.48.5]:41174) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oolwl-0000vY-Rf for 58739-done@debbugs.gnu.org; Sat, 29 Oct 2022 09:32:25 -0400 Received: (qmail 29022 invoked by uid 3782); 29 Oct 2022 15:32:17 +0200 Received: from acm.muc.de (p4fe15996.dip0.t-ipconnect.de [79.225.89.150]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 Oct 2022 15:32:17 +0200 Received: (qmail 32729 invoked by uid 1000); 29 Oct 2022 13:32:13 -0000 Date: Sat, 29 Oct 2022 13:32:13 +0000 To: 58739-done@debbugs.gnu.org Subject: Re: bug#58739: Fixed Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58739-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Bug fixed. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Sat Oct 29 12:04:34 2022 Received: (at 58739) by debbugs.gnu.org; 29 Oct 2022 16:04:34 +0000 Received: from localhost ([127.0.0.1]:36430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oooK1-0007FH-MJ for submit@debbugs.gnu.org; Sat, 29 Oct 2022 12:04:33 -0400 Received: from mx3.muc.de ([193.149.48.5]:45648) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oooK0-0007F1-9V for 58739@debbugs.gnu.org; Sat, 29 Oct 2022 12:04:33 -0400 Received: (qmail 79873 invoked by uid 3782); 29 Oct 2022 18:04:26 +0200 Received: from acm.muc.de (p4fe15996.dip0.t-ipconnect.de [79.225.89.150]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 29 Oct 2022 18:04:26 +0200 Received: (qmail 23279 invoked by uid 1000); 29 Oct 2022 16:04:22 -0000 Date: Sat, 29 Oct 2022 16:04:22 +0000 To: Eli Zaretskii Subject: Re: bug#58739: Lack of error message about number of args (?native compilation?) Message-ID: References: <831qqqiyn0.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <831qqqiyn0.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 58739 Cc: 58739@debbugs.gnu.org, akrl@sdf.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Sat, Oct 29, 2022 at 15:48:35 +0300, Eli Zaretskii wrote: > > Cc: 58739@debbugs.gnu.org > > Date: Sat, 29 Oct 2022 12:04:36 +0000 > > From: Alan Mackenzie > > > to me this fix looks like a good idea (assuming changing the definition > > > of MANY is acceptable). > > We'll see what Eli says. > About what, may I ask? My patch for this bug. As a quick summary, the cause of spurious warning messages in the byte compiler was subr-arity returning (12 . many) rather than the correct (12 . 12) for a native compiled function with exactly 12 parameters. I've corrected this, by making subr-arity return (12 . 12), and I committed the patch earlier on this afternoon. In the process, MANY came to be defined to mean "has &rest parameters". I think you'll be interested in the patch. -- Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 31 09:15:25 2022 Received: (at 58739) by debbugs.gnu.org; 31 Oct 2022 13:15:25 +0000 Received: from localhost ([127.0.0.1]:39764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opUdR-0006uA-9r for submit@debbugs.gnu.org; Mon, 31 Oct 2022 09:15:25 -0400 Received: from mx.sdf.org ([205.166.94.24]:49594) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opUdM-0006bd-0X for 58739@debbugs.gnu.org; Mon, 31 Oct 2022 09:15:23 -0400 Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 29VDFIKG020623 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 31 Oct 2022 13:15:18 GMT From: Andrea Corallo To: Alan Mackenzie Subject: Re: bug#58739: Lack of error message about number of args (?native compilation?) In-Reply-To: (Alan Mackenzie's message of "Sat, 29 Oct 2022 12:04:36 +0000") References: Date: Mon, 31 Oct 2022 13:15:18 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 58739 Cc: 58739@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Alan Mackenzie writes: > Hello, Andrea. > > On Tue, Oct 25, 2022 at 20:15:38 +0000, Andrea Corallo wrote: >> Alan Mackenzie writes: > >> > On Sun, Oct 23, 2022 at 12:12:49 +0000, Alan Mackenzie wrote: > > [ .... ] > >> >> As a matter of interest, I noticed this bug while byte-compiling >> >> desktop.el inside Emacs. It gave a warning message about the number of >> >> parameters to desktop-buffer having changed from 12+ to 12. > >> >> Here, I suspect there's a bug in the native compilation of >> >> desktop-buffer. > >> > The problem here is that (func-arity 'desktop-buffer) returns (12 . 12) on a >> > byte compiled desktop.elc, but (12 . many) on the corresponding .eln file. >> > This (12 . many) must be regarded as a bug, since there are no &rest >> > parameters in desktop-buffer. > >> > I propose a minor amendment to the definition of MANY, such that it will >> > mean "there are &rest parameters", rather than "the calling convention >> > is with nargs + *args". I have implemented this, and my patch is below. > >> > What I want to ask you to check is that in the native compiler, when >> > declare_imported_func encounters a function with, say, exactly 12 >> > arguments, it will throw an error. I think this is actually correct, >> > since the compiler cannot know whether this function uses the subr >> > calling convention of nargs + *args, or the byte coded convention of >> > pushing the 12 arguments individually onto the stack. Is throwing this >> > error a good idea? > >> Hi Alan, > >> to me this fix looks like a good idea (assuming changing the definition >> of MANY is acceptable). > > We'll see what Eli says. > >> I think also that throwing the error in 'declare_imported_func' is okay >> at this point. > > Apologies at this point. I should have produced an error from this > before bothering you. I was unable to produce such an error, and I've > spent the last few days understanding what happens here, with this > result: > > A call from a native compiled function is always in the form nargs + > *args, regardless of whether there are more than 8 arguments or not. > More accurately, the call to an unknown type of function (.eln/.elc/.el) > puts the function (in some form, I don't know exactly what) at element 0 > of *args, and the arguments themselves starting at element 1 of *args. > It then calls Ffuncall (or something like it). > > When the called function is a byte-code function, further down the call > stack exec_byte_code gets called with this (nargs + 1) + *args. > exec_byte_code then pushes the arguments onto the stack before > interpreting the byte code. > > So this "problem" with the native compiler not knowing what call sequence > to generate isn't a problem at all. It's all dealt with at run time. No > doubt this slows down Emacs quite a bit, but it's safe. > > So I'll take that bit out of my patch, and commit the rest of it to > master, and see what happens from there. Hi Alan, That's correct. As you prefer, we could also keep it as assertion. Thanks Andrea From unknown Mon Jun 23 07:47:40 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 29 Nov 2022 12:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator