From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Correct byte compiler error/warning positions. The solution! Date: Sat, 27 Nov 2021 23:05:12 +0000 Message-ID: References: <83pmqm16vz.fsf@gnu.org> <8335nh29pt.fsf@gnu.org> <83wnktzxb2.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36286"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 28 00:06:16 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mr6ls-0009Dx-NC for ged-emacs-devel@m.gmane-mx.org; Sun, 28 Nov 2021 00:06:16 +0100 Original-Received: from localhost ([::1]:52008 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mr6lr-0003H6-4r for ged-emacs-devel@m.gmane-mx.org; Sat, 27 Nov 2021 18:06:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53724) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mr6lJ-0002Vy-0U for emacs-devel@gnu.org; Sat, 27 Nov 2021 18:05:41 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:10332 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1mr6lH-0007Ih-0M for emacs-devel@gnu.org; Sat, 27 Nov 2021 18:05:40 -0500 Original-Received: (qmail 5263 invoked by uid 3782); 27 Nov 2021 23:05:12 -0000 Original-Received: from acm.muc.de (p2e5d5030.dip0.t-ipconnect.de [46.93.80.48]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 28 Nov 2021 00:05:12 +0100 Original-Received: (qmail 9904 invoked by uid 1000); 27 Nov 2021 23:05:12 -0000 Content-Disposition: inline In-Reply-To: <83wnktzxb2.fsf@gnu.org> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.1; envelope-from=acm@muc.de; helo=mail.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=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:280358 Archived-At: Hello, Eli. On Sat, Nov 27, 2021 at 12:51:13 +0200, Eli Zaretskii wrote: > > Date: Sat, 27 Nov 2021 10:33:07 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > > I meant that NILP will be implemented as a binary comparison against > > > > zero, omitting the awkward test for symbols_with_position_enabled. > > > Please don't write code that assumes Qnil is zero. (Or maybe I still > > > misunderstand what exactly you mean by the above.) > > Don't worry! The new code merely assumes Qnil is a symbol, and leaves it > > to the compiler to optimise for Qnil being binary zero. > Once again, you cannot compare structures with == in portable C. And > the Lisp_Object type can be struct. As long as what you say above > doesn't mean that you compare with ==, I'm okay with what you propose. Sorry, I was perhaps a wee bit too informal when I said "==". The actual code in lisp.h looks like this: #define lisp_h_NILP(x) ((XLI (x) == XLI (Qnil))) .. Anyhow, it's now working! I can bootstrap the new code, although I haven't tried it with native compilation, yet. For timings, I've used my favourite informal benchmark, M-; (time-scroll) on xdisp.c: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defmacro time-it (&rest forms) "Time the running of a sequence of forms using `float-time'. Call like this: \"M-: (time-it (foo ...) (bar ...) ...)\"." `(let ((start (float-time))) ,@forms (- (float-time) start))) (defun time-scroll (&optional arg) (interactive "P") (message "%s" (time-it (condition-case nil (while t (if arg (scroll-down) (scroll-up)) (sit-for 0)) (error nil))))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; The timings I have for scrolling in the forward direction (each time preceded by M-x garbage-collect, and typing/erasing a character to clear the font-lock settings) are: (master branch, no native compilation): 20.847s, 21.609s, 19.459s, 21.570s, 21.651 (New code with correct warning messages, no native compilation): 21.284s, 42.152s ????, 19.927s, 19.960s, 22.259s, 22.198, 22.209s. The input to configure was the same in both cases, namely ./configure --with-gif=no --with-tiff=no --with-gpm. , and the timings were done on the Linux console. No, I don't understand that 42s run. A lot of garbage collection, perhaps? But otherwise, the timings are broadly similar, with the new code being slightly slower. But the variations between runs is more significant than the variation between versions. On bug ~9109 from Roland Winkler: (unwind-protect (let ((foo "foo")) (insert foo)) (setq foo "bar")) Byte compiling this with M-x compile-defun on master produces this warning message: Buffer winkler.el:2:12: Warning: assignment to free variable `foo' The position 2:12 is clearly wrong. Byte compiling it with the new code produces: Buffer winkler.el:2:12:4:9: Warning: assignment to free variable `#'. There, there are two positions the (old, temporary) 2:12 and the (new, correct) 4:9. There is a bit of tidying up of the mechanism to be done here, obviously, but the correct position is demonstrated. -- Alan Mackenzie (Nuremberg, Germany).