From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 27 10:49:42 2021 Received: (at submit) by debbugs.gnu.org; 27 Apr 2021 14:49:42 +0000 Received: from localhost ([127.0.0.1]:50504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbP1y-0002Y8-39 for submit@debbugs.gnu.org; Tue, 27 Apr 2021 10:49:42 -0400 Received: from lists.gnu.org ([209.51.188.17]:53676) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbP1w-0002Xz-DZ for submit@debbugs.gnu.org; Tue, 27 Apr 2021 10:49:41 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49068) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lbP1w-0007h1-5j for bug-gnu-emacs@gnu.org; Tue, 27 Apr 2021 10:49:40 -0400 Received: from colin.muc.de ([193.149.48.1]:19197 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.90_1) (envelope-from ) id 1lbP1u-0007JN-1g for bug-gnu-emacs@gnu.org; Tue, 27 Apr 2021 10:49:39 -0400 Received: (qmail 55531 invoked by uid 3782); 27 Apr 2021 14:49:32 -0000 Received: from acm.muc.de (p4fe15a60.dip0.t-ipconnect.de [79.225.90.96]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 27 Apr 2021 16:49:31 +0200 Received: (qmail 4950 invoked by uid 1000); 27 Apr 2021 14:49:31 -0000 Date: Tue, 27 Apr 2021 14:49:31 +0000 To: bug-gnu-emacs@gnu.org Subject: Unexpected result from a native-compiled function 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.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=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.6 (-) 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.6 (--) 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). From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 27 13:20:32 2021 Received: (at 48061) by debbugs.gnu.org; 27 Apr 2021 17:20:32 +0000 Received: from localhost ([127.0.0.1]:50796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbRNw-0002VQ-0Z for submit@debbugs.gnu.org; Tue, 27 Apr 2021 13:20:32 -0400 Received: from colin.muc.de ([193.149.48.1]:23305 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lbRNu-0002VB-Ew for 48061@debbugs.gnu.org; Tue, 27 Apr 2021 13:20:31 -0400 Received: (qmail 61304 invoked by uid 3782); 27 Apr 2021 17:20:23 -0000 Received: from acm.muc.de (p4fe15a60.dip0.t-ipconnect.de [79.225.90.96]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 27 Apr 2021 19:20:23 +0200 Received: (qmail 6651 invoked by uid 1000); 27 Apr 2021 17:20:22 -0000 Date: Tue, 27 Apr 2021 17:20:22 +0000 To: 48061@debbugs.gnu.org Subject: Re: bug#48061: Unexpected result from a native-compiled function 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: 48061 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 Tue, Apr 27, 2021 at 14:49:31 +0000, Alan Mackenzie wrote: > 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). I've now managed to get a decent disassembly, and there is indeed a missing machine instruction in the code which causes it to fail: The function is: ######################################################################### (defun c-determine-limit-no-macro (here org-start) ;; If HERE is inside a macro, and ORG-START is not also in the same macro, ;; return the beginning of the macro. Otherwise return HERE. Point is not ;; preserved by this function. (goto-char here) (let ((here-BOM (and (c-beginning-of-macro) (point)))) (if (and here-BOM (not (eq (progn (goto-char org-start) (and (c-beginning-of-macro) (point))) here-BOM))) here-BOM here))) ######################################################################### The register use in the compiled function is: rbp here r12 org-start r13 here-BOM The disassembly (with some added notes) is this: 00000000000264f0 : 264f0: 41 56 push %r14 264f2: 41 55 push %r13 264f4: 41 54 push %r12 264f6: 49 89 f4 mov %rsi,%r12 org-start 264f9: 55 push %rbp 264fa: 48 89 fd mov %rdi,%rbp here 264fd: 53 push %rbx 264fe: 48 83 ec 20 sub $0x20,%rsp 26502: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax 26509: 00 00 2650b: 48 89 44 24 18 mov %rax,0x18(%rsp) 26510: 48 8b 05 d1 2a 27 00 mov 0x272ad1(%rip),%rax # 298fe8 <_DYNAMIC+0x1f8> 26517: 48 8b 18 mov (%rax),%rbx 2651a: ff 93 b8 14 00 00 callq *0x14b8(%rbx) goto-char 26520: 48 8d 74 24 08 lea 0x8(%rsp),%rsi 26525: bf 01 00 00 00 mov $0x1,%edi 2652a: 4c 8b 35 af 2a 27 00 mov 0x272aaf(%rip),%r14 # 298fe0 <_DYNAMIC+0x1f0> 26531: 49 8b 86 c8 00 00 00 mov 0xc8(%r14),%rax 26538: 48 89 44 24 08 mov %rax,0x8(%rsp) 2653d: ff 93 08 1a 00 00 callq *0x1a08(%rbx) c-beginning-of-macro 26543: 48 85 c0 test %rax,%rax 26546: 74 52 je 2659a 26548: ff 93 68 14 00 00 callq *0x1468(%rbx) point 2654e: 49 89 c5 mov %rax,%r13 here-BOM 26551: 48 85 c0 test %rax,%rax 26554: 74 44 je 2659a 26556: 4c 89 e7 mov %r12,%rdi org-start 26559: ff 93 b8 14 00 00 callq *0x14b8(%rbx) goto-char 2655f: bf 01 00 00 00 mov $0x1,%edi 26564: 48 8d 74 24 10 lea 0x10(%rsp),%rsi 26569: 49 8b 86 c8 00 00 00 mov 0xc8(%r14),%rax 26570: 48 89 44 24 10 mov %rax,0x10(%rsp) 26575: ff 93 08 1a 00 00 callq *0x1a08(%rbx) c-beginning-of-macro 2657b: 48 89 c7 mov %rax,%rdi 2657e: 48 85 c0 test %rax,%rax 26581: 74 09 je 2658c 26583: ff 93 68 14 00 00 callq *0x1468(%rbx) point 26589: 48 89 c7 mov %rax,%rdi 2658c: 4c 89 ee mov %r13,%rsi here-BOM 2658f: ff 93 60 27 00 00 callq *0x2760(%rbx) eq 26595: 48 85 c0 test %rax,%rax <======================================================== 26598: 74 03 je 2659d 2659a: 48 89 e8 mov %rbp,%rax here 2659d: 48 8b 54 24 18 mov 0x18(%rsp),%rdx 265a2: 64 48 2b 14 25 28 00 sub %fs:0x28,%rdx 265a9: 00 00 265ab: 75 0d jne 265ba 265ad: 48 83 c4 20 add $0x20,%rsp 265b1: 5b pop %rbx 265b2: 5d pop %rbp 265b3: 41 5c pop %r12 265b5: 41 5d pop %r13 265b7: 41 5e pop %r14 265b9: c3 retq 265ba: e8 41 12 fe ff callq 7800 <__stack_chk_fail@plt> 265bf: 90 nop 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. > -- > Alan Mackenzie (Nuremberg, Germany). From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 27 16:02:52 2021 Received: (at 48061) by debbugs.gnu.org; 27 Apr 2021 20:02:52 +0000 Received: from localhost ([127.0.0.1]:50991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbTv2-0006WQ-7w for submit@debbugs.gnu.org; Tue, 27 Apr 2021 16:02:52 -0400 Received: from mx.sdf.org ([205.166.94.24]:63245) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbTuz-0006WF-R7 for 48061@debbugs.gnu.org; Tue, 27 Apr 2021 16:02:50 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 13RK2jvd023521 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 27 Apr 2021 20:02:46 GMT From: Andrea Corallo To: Alan Mackenzie Subject: Re: bug#48061: Unexpected result from a native-compiled function References: Date: Tue, 27 Apr 2021 20:02:45 +0000 In-Reply-To: (Alan Mackenzie's message of "Tue, 27 Apr 2021 17:20:22 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 48061 Cc: 48061@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: > On Tue, Apr 27, 2021 at 14:49:31 +0000, Alan Mackenzie wrote: >> 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). > > I've now managed to get a decent disassembly, and there is indeed a > missing machine instruction in the code which causes it to fail: > > The function is: > > ######################################################################### > (defun c-determine-limit-no-macro (here org-start) > ;; If HERE is inside a macro, and ORG-START is not also in the same macro, > ;; return the beginning of the macro. Otherwise return HERE. Point is not > ;; preserved by this function. > (goto-char here) > (let ((here-BOM (and (c-beginning-of-macro) (point)))) > (if (and here-BOM > (not (eq (progn (goto-char org-start) > (and (c-beginning-of-macro) (point))) > here-BOM))) > here-BOM > here))) > ######################################################################### > > The register use in the compiled function is: > > rbp here > r12 org-start > r13 here-BOM > > The disassembly (with some added notes) is this: > > 00000000000264f0 : > 264f0: 41 56 push %r14 [...] > 26583: ff 93 68 14 00 00 callq *0x1468(%rbx) point > 26589: 48 89 c7 mov %rax,%rdi > 2658c: 4c 89 ee mov %r13,%rsi here-BOM > 2658f: ff 93 60 27 00 00 callq *0x2760(%rbx) eq > 26595: 48 85 c0 test %rax,%rax <======================================================== > 26598: 74 03 je 2659d > 2659a: 48 89 e8 mov %rbp,%rax here > 2659d: 48 8b 54 24 18 mov 0x18(%rsp),%rdx > 265a2: 64 48 2b 14 25 28 00 sub %fs:0x28,%rdx > 265a9: 00 00 > 265ab: 75 0d jne 265ba > 265ad: 48 83 c4 20 add $0x20,%rsp > 265b1: 5b pop %rbx > 265b2: 5d pop %rbp > 265b3: 41 5c pop %r12 > 265b5: 41 5d pop %r13 > 265b7: 41 5e pop %r14 > 265b9: c3 retq > 265ba: e8 41 12 fe ff callq 7800 <__stack_chk_fail@plt> > 265bf: 90 nop > > 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. Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 27 17:03:11 2021 Received: (at 48061) by debbugs.gnu.org; 27 Apr 2021 21:03:11 +0000 Received: from localhost ([127.0.0.1]:51051 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbUrP-0007xk-0L for submit@debbugs.gnu.org; Tue, 27 Apr 2021 17:03:11 -0400 Received: from mx.sdf.org ([205.166.94.24]:56657) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbUrK-0007xZ-W7 for 48061@debbugs.gnu.org; Tue, 27 Apr 2021 17:03:10 -0400 Received: from mab (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 13RL35I9004637 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Tue, 27 Apr 2021 21:03:05 GMT From: Andrea Corallo To: Alan Mackenzie Subject: Re: bug#48061: Unexpected result from a native-compiled function References: Date: Tue, 27 Apr 2021 21:03:05 +0000 In-Reply-To: (Andrea Corallo via's message of "Tue, 27 Apr 2021 20:02:45 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 48061 Cc: 48061@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 (-) Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Alan Mackenzie writes: > >> On Tue, Apr 27, 2021 at 14:49:31 +0000, Alan Mackenzie wrote: >>> 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). >> >> I've now managed to get a decent disassembly, and there is indeed a >> missing machine instruction in the code which causes it to fail: >> >> The function is: >> >> ######################################################################### >> (defun c-determine-limit-no-macro (here org-start) >> ;; If HERE is inside a macro, and ORG-START is not also in the same macro, >> ;; return the beginning of the macro. Otherwise return HERE. Point is not >> ;; preserved by this function. >> (goto-char here) >> (let ((here-BOM (and (c-beginning-of-macro) (point)))) >> (if (and here-BOM >> (not (eq (progn (goto-char org-start) >> (and (c-beginning-of-macro) (point))) >> here-BOM))) >> here-BOM >> here))) >> ######################################################################### >> >> The register use in the compiled function is: >> >> rbp here >> r12 org-start >> r13 here-BOM >> >> The disassembly (with some added notes) is this: >> >> 00000000000264f0 : >> 264f0: 41 56 push %r14 > > [...] > >> 26583: ff 93 68 14 00 00 callq *0x1468(%rbx) point >> 26589: 48 89 c7 mov %rax,%rdi >> 2658c: 4c 89 ee mov %r13,%rsi here-BOM >> 2658f: ff 93 60 27 00 00 callq *0x2760(%rbx) eq >> 26595: 48 85 c0 test %rax,%rax <======================================================== >> 26598: 74 03 je 2659d >> 2659a: 48 89 e8 mov %rbp,%rax here >> 2659d: 48 8b 54 24 18 mov 0x18(%rsp),%rdx >> 265a2: 64 48 2b 14 25 28 00 sub %fs:0x28,%rdx >> 265a9: 00 00 >> 265ab: 75 0d jne 265ba >> 265ad: 48 83 c4 20 add $0x20,%rsp >> 265b1: 5b pop %rbx >> 265b2: 5d pop %rbp >> 265b3: 41 5c pop %r12 >> 265b5: 41 5d pop %r13 >> 265b7: 41 5e pop %r14 >> 265b9: c3 retq >> 265ba: e8 41 12 fe ff callq 7800 <__stack_chk_fail@plt> >> 265bf: 90 nop >> >> 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 :) Thanks Andrea From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 28 05:19:18 2021 Received: (at 48061-done) by debbugs.gnu.org; 28 Apr 2021 09:19:18 +0000 Received: from localhost ([127.0.0.1]:51715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lbgLm-0003VT-CE for submit@debbugs.gnu.org; Wed, 28 Apr 2021 05:19:18 -0400 Received: from colin.muc.de ([193.149.48.1]:48588 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lbgLk-0003VD-NE for 48061-done@debbugs.gnu.org; Wed, 28 Apr 2021 05:19:17 -0400 Received: (qmail 86684 invoked by uid 3782); 28 Apr 2021 09:19:09 -0000 Received: from acm.muc.de (p4fe15c50.dip0.t-ipconnect.de [79.225.92.80]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 28 Apr 2021 11:19:09 +0200 Received: (qmail 5286 invoked by uid 1000); 28 Apr 2021 09:19:09 -0000 Date: Wed, 28 Apr 2021 09:19:09 +0000 To: Andrea Corallo Subject: Re: bug#48061: Unexpected result from a native-compiled function 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: 48061-done Cc: 48061-done@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 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" 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). From debbugs-submit-bounces@debbugs.gnu.org Sun May 09 05:34:00 2021 Received: (at control) by debbugs.gnu.org; 9 May 2021 09:34:00 +0000 Received: from localhost ([127.0.0.1]:55182 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lffp2-0002wG-8J for submit@debbugs.gnu.org; Sun, 09 May 2021 05:34:00 -0400 Received: from colin.muc.de ([193.149.48.1]:12284 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1lffp0-0002w5-37 for control@debbugs.gnu.org; Sun, 09 May 2021 05:33:58 -0400 Received: (qmail 87140 invoked by uid 3782); 9 May 2021 09:33:51 -0000 Received: from acm.muc.de (p2e5d56ec.dip0.t-ipconnect.de [46.93.86.236]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 09 May 2021 11:33:50 +0200 Received: (qmail 5548 invoked by uid 1000); 9 May 2021 09:33:50 -0000 Date: Sun, 9 May 2021 09:33:50 +0000 To: Paul Nelson Subject: Re: bug#48100: 28.0.50; inserting too many lines into a fresh cpp file breaks the buffer Message-ID: References: <87a6pd45w6.fsf@tcd.ie> 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: control Cc: "Basil L. Contovounesios" , acm@muc.de, Lars Ingebrigtsen , control@debbugs.gnu.org, 48100-done@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 (-) close 48100 merge 48061 48100 quit Hello, Paul. On Thu, May 06, 2021 at 12:26:12 +0200, Paul Nelson wrote: > Hi Alan, > Looks good after updating -- seems like it was indeed a repeat of #48061. > Thanks for your help! I'll report back if anything similar comes up again. Thanks, I'm glad it's fixed. I'm closing the bug with this post, and trying to merge it into bug #48061, the first bug where c-determine-limit-no-macro miscompiled. > Paul -- Alan Mackenzie (Nuremberg, Germany). From unknown Mon Jun 16 23:55:16 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 06 Jun 2021 11:24:04 +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