--- Begin Message ---
|
Subject: |
Unexpected result from a native-compiled function |
|
Date: |
Tue, 27 Apr 2021 14:49:31 +0000 |
Hello, Emacs.
In certain circumstances (see below for recipe), the natively compiled
version of c-determine-limit-no-macro returns an invalid result, nil.
In the same circumstances, the edebug instrumented version returns the
correct result, a buffer position.
So far I have tried M-x disassemble RET c-determine-limit-no-macro, but
I wasn't able to follow the output (there were no symbols in the
listing).
Question: what else can I do to help isolate and fix this bug?
Recipe for reproduction:
In GNU Emacs 28.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version
3.24.26, cairo version 1.16.0)
of 2021-04-25 built on ACM
Repository revision: 83a915d3dfafd5f3d737afe1e13b75e4dd3aef96
Repository branch: master
System Description: Gentoo/Linux
Configured using:
'configure --with-gif=no --with-tiff=no --with-gpm
--with-native-compilation'
(i) emacs -Q
(ii) Make sure CC Mode is natively compiled and loaded into an Emacs
session.
(iii) Evaluate the following (an attempt to time CC Mode's indentation
speed):
(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-indent ()
(interactive)
(save-excursion
(goto-char (point-min))
(while (not (eobp))
(delete-horizontal-space)
(beginning-of-line 2))
(goto-char (point-min))
(message "%s"
(time-it
(while (not (eobp))
(c-indent-line)
(beginning-of-line 2))))))
(iv) Load src/minibuf.c into a buffer.
(v) M-: (time-indent) RET
This throws an error at line 606 in minibuf.c. point is at 16972, at
BOL.
(vi) With the current buffer minibuf.c, M-: (c-determine-limit-no-macro
16367 16972) RET. This returns the invalid result nil. This looks like
a bug.
(vii) Load lisp/progmodes/cc-engine.el into another buffer. Move to the
definition of c-determine-limit-no-macro at line 5795. Instrument the
function for edebug with C-u C-M-x.
(viii) M-: (c-determine-limit-no-macro 16367 16972) RET, followed by the
edebug command c. This indicates the expected result 16350, which is
different from the nil returned in (vi).
--
Alan Mackenzie (Nuremberg, Germany).
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#48061: Unexpected result from a native-compiled function |
|
Date: |
Wed, 28 Apr 2021 09:19:09 +0000 |
Hello, Andrea.
On Tue, Apr 27, 2021 at 21:03:05 +0000, Andrea Corallo wrote:
> Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
[ .... ]
> >> After the indicated line (0x26595), when 0x0 (nil) is in rax (i.e. the
> >> `eq' function has returned nil) the result of the function should be
> >> here-BOM, i.e. r13. There is no instruction
> >> mov %r13,%rax
> >> to effect this return. Instead, rax is still holding nil, and this is
> >> falsely returned.
> > Hi Alan,
> > thanks for investigating this! I had a quick look and I think I see
> > what's the issue, I'll follow up when I've the fix.
> Hi Alan,
> looking at the intermediate representation of this interesting function
> I've fixed a bug, I can't prove it solves your issue as I've no
> reproducer tho.
> Could you try if as of 4e1e0b9dec this is solved? If is not the case
> could you provide a reproducer so I'll not disturb next time until is
> solved :)
The bug fix does indeed fix my problem. :-) My test case now runs to
the end without error, and I had a look at the disassembly too, in which
I no longer see the problem from yesterday.
I'm closing the bug with this post.
Thanks!
> Thanks
> Andrea
--
Alan Mackenzie (Nuremberg, Germany).
--- End Message ---