bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Erik Hetzner]

Hi all,

There is a difference between native compiled code and non-native
compiled code that the wanderlust community has surfaced. It is not
clear to me why this is happening.

Steps to reproduce:

1. Start emacs -q

2. Eval the following code:
```
(require 'comp)
(setq package-native-compile t
      package-archives
      '(("melpa" . "https://melpa.org/packages/")
        ("gnu" . "http://elpa.gnu.org/packages/")))
(package-initialize)
(package-refresh-contents)
(package-install 'flim)
 (while (or comp-files-queue
            (> (comp-async-runnings) 0))
   (sleep-for 1))
(require 'mel)
(message (encoded-text-decode-string "QUJD" "B"))
```
It should print: "ABC"

3. Quit emacs. (This seems necessary, but I'm not sure why.)

4. Start emacs -q again.

5. Eval the code again.

Expected result: "ABC". Actual result:

```
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p "QUJD")
  encoded-text-decode-string("QUJD" "B")
  (message (encoded-text-decode-string "QUJD" "B"))
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  command-execute(eval-last-sexp)
```

See also https://github.com/wanderlust/wanderlust/issues/156

best, Erik Hetzner

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 1.16.0)
 of 2021-03-04 built on lcy01-amd64-015
Repository revision: b9ccbac7685620d4624f55b9de361c610ede8aa4
Repository branch: feature/native-comp
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid

Configured using:
 'configure --prefix=/snap/emacs/current/usr --with-x-toolkit=gtk3
 --without-xaw3d --with-modules --with-cairo --with-native-compilation
 'CFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
 -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu
 -O2' 'CPPFLAGS=-isystem/build/emacs/parts/emacs/install/usr/include
 -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu'
 'LDFLAGS=-L/build/emacs/parts/emacs/install/lib
 -L/build/emacs/parts/emacs/install/usr/lib
 -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu
 -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu''

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES
NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF
TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa easymenu derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar
dnd fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors frame minibuffer cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face pcase macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads dbusbind
inotify lcms2 dynamic-setting system-font-setting font-render-setting
cairo move-toolbar gtk x-toolkit x multi-tty make-network-process
nativecomp emacs)

Memory information:
((conses 16 72422 3962)
 (symbols 48 6708 0)
 (strings 32 19712 2887)
 (string-bytes 1 675546)
 (vectors 16 14136)
 (vector-slots 8 287845 10043)
 (floats 8 22 30)
 (intervals 56 294 0)
 (buffers 992 12))

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Pip Cet]

[-- Attachment #1: Type: text/plain, Size: 358 bytes --]

On Sat, Mar 6, 2021 at 7:22 PM Erik Hetzner <egh@e6h.org> wrote:
> Hi all,
>
> There is a difference between native compiled code and non-native
> compiled code that the wanderlust community has surfaced. It is not
> clear to me why this is happening.

Can you try this patch? It might help, or not, but it should be
applied in any case. Cc'ing Andrea.

Pip

[-- Attachment #2: bug46974.diff --]
[-- Type: text/x-patch, Size: 919 bytes --]

diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
index 4a418c1aadebc..8d65d6c1c65e3 100644
--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -3283,11 +3283,13 @@ comp-call-optim-func
    do (comp-loop-insn-in-block b
         (pcase insn
           (`(set ,lval (callref funcall ,f . ,rest))
-           (when-let ((new-form (comp-call-optim-form-call
+           (when-let ((ok (comp-cstr-imm-vld-p f))
+                      (new-form (comp-call-optim-form-call
                                  (comp-cstr-imm f) rest)))
              (setf insn `(set ,lval ,new-form))))
           (`(callref funcall ,f . ,rest)
-           (when-let ((new-form (comp-call-optim-form-call
+           (when-let ((ok (comp-cstr-imm-vld-p f))
+                      (new-form (comp-call-optim-form-call
                                  (comp-cstr-imm f) rest)))
              (setf insn new-form)))))))
 

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pip Cet <pipcet@gmail.com> writes:

> On Sat, Mar 6, 2021 at 7:22 PM Erik Hetzner <egh@e6h.org> wrote:
>> Hi all,
>>
>> There is a difference between native compiled code and non-native
>> compiled code that the wanderlust community has surfaced. It is not
>> clear to me why this is happening.
>
> Can you try this patch? It might help, or not, but it should be
> applied in any case. Cc'ing Andrea.
>
> Pip

Hi Pip,

the patch LGTM, please feel free to apply it once tested.

Thanks for spotting this.

  Andrea

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Erik Hetzner]

Hi all,

On Sat, 06 Mar 2021 12:49:18 -0800,
Andrea Corallo via
 "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org> wrote:
> 
> Pip Cet <pipcet@gmail.com> writes:
> 
> > On Sat, Mar 6, 2021 at 7:22 PM Erik Hetzner <egh@e6h.org> wrote:
> >> Hi all,
> >>
> >> There is a difference between native compiled code and non-native
> >> compiled code that the wanderlust community has surfaced. It is not
> >> clear to me why this is happening.
> >
> > Can you try this patch? It might help, or not, but it should be
> > applied in any case. Cc'ing Andrea.
> >
> > Pip
> 
> Hi Pip,
> 
> the patch LGTM, please feel free to apply it once tested.
> 
> Thanks for spotting this.

This seems to have fixed the issue. I built from c60f2f4 and I don’t
see the issue. Thank you so much!

best, Erik Hetzner

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Pip Cet]

On Sun, Mar 7, 2021 at 3:24 AM Erik Hetzner <egh@e6h.org> wrote:
> This seems to have fixed the issue. I built from c60f2f4 and I don’t
> see the issue. Thank you so much!

I'm being bold and closing this, as I'm pretty sure it was due to the
bug we fixed. Please reopen if necessary.

Thanks
Pip

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pip Cet <pipcet@gmail.com> writes:

> On Sun, Mar 7, 2021 at 3:24 AM Erik Hetzner <egh@e6h.org> wrote:
>> This seems to have fixed the issue. I built from c60f2f4 and I don’t
>> see the issue. Thank you so much!
>
> I'm being bold and closing this, as I'm pretty sure it was due to the
> bug we fixed. Please reopen if necessary.

The fact that you feel sure about this make me suspecting that you may
already have a reproducer for this :)

*If* that's really the case I think would be nice to add it as a
testcase, if it's not never mind.

Thanks

  Andrea

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Pip Cet]

On Sun, Mar 7, 2021 at 7:41 PM Andrea Corallo <akrl@sdf.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
> > On Sun, Mar 7, 2021 at 3:24 AM Erik Hetzner <egh@e6h.org> wrote:
> >> This seems to have fixed the issue. I built from c60f2f4 and I don’t
> >> see the issue. Thank you so much!
> >
> > I'm being bold and closing this, as I'm pretty sure it was due to the
> > bug we fixed. Please reopen if necessary.
>
> The fact that you feel sure about this make me suspecting that you may
> already have a reproducer for this :)

Nah, I'm probably just over-confident :-) . I did reproduce this, but
only in a live session.

Perfectly open question: how would you feel about adding LAP
reproducers for cases like this one, where it's hard to get at the
Lisp source? I think I've got the reproducer LAP code here, and it
shouldn't be too hard to write comp--native-compile-lap, but if you'd
prefer not to go that way I'm perfectly okay with it, too.

Pip

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pip Cet <pipcet@gmail.com> writes:

> On Sun, Mar 7, 2021 at 7:41 PM Andrea Corallo <akrl@sdf.org> wrote:
>> Pip Cet <pipcet@gmail.com> writes:
>> > On Sun, Mar 7, 2021 at 3:24 AM Erik Hetzner <egh@e6h.org> wrote:
>> >> This seems to have fixed the issue. I built from c60f2f4 and I don’t
>> >> see the issue. Thank you so much!
>> >
>> > I'm being bold and closing this, as I'm pretty sure it was due to the
>> > bug we fixed. Please reopen if necessary.
>>
>> The fact that you feel sure about this make me suspecting that you may
>> already have a reproducer for this :)
>
> Nah, I'm probably just over-confident :-) . I did reproduce this, but
> only in a live session.

Mine was a good try :D

> Perfectly open question: how would you feel about adding LAP
> reproducers for cases like this one, where it's hard to get at the
> Lisp source? I think I've got the reproducer LAP code here, and it
> shouldn't be too hard to write comp--native-compile-lap, but if you'd
> prefer not to go that way I'm perfectly okay with it, too.

I'm open to the idea of having a new way to stress the code in the
testsuite, I'm a little doubtful this worth of, well certainly for this
specific case where the patch is clearly correct.

What's your feeling about this?

  Andrea

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Pip Cet]

On Sun, Mar 7, 2021 at 8:33 PM Andrea Corallo <akrl@sdf.org> wrote:
> Pip Cet <pipcet@gmail.com> writes:
> > Perfectly open question: how would you feel about adding LAP
> > reproducers for cases like this one, where it's hard to get at the
> > Lisp source? I think I've got the reproducer LAP code here, and it
> > shouldn't be too hard to write comp--native-compile-lap, but if you'd
> > prefer not to go that way I'm perfectly okay with it, too.
>
> I'm open to the idea of having a new way to stress the code in the
> testsuite, I'm a little doubtful this worth of, well certainly for this
> specific case where the patch is clearly correct.
>
> What's your feeling about this?

I think this is going to be something we want eventually, but it's
harder than I thought, so I won't pursue this for now.

Pip

bug#46974: 28.0.50; [nativecomp] wrong-type-argument number-or-marker-p with native compiled code only

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Pip Cet <pipcet@gmail.com> writes:

> On Sun, Mar 7, 2021 at 8:33 PM Andrea Corallo <akrl@sdf.org> wrote:
>> Pip Cet <pipcet@gmail.com> writes:
>> > Perfectly open question: how would you feel about adding LAP
>> > reproducers for cases like this one, where it's hard to get at the
>> > Lisp source? I think I've got the reproducer LAP code here, and it
>> > shouldn't be too hard to write comp--native-compile-lap, but if you'd
>> > prefer not to go that way I'm perfectly okay with it, too.
>>
>> I'm open to the idea of having a new way to stress the code in the
>> testsuite, I'm a little doubtful this worth of, well certainly for this
>> specific case where the patch is clearly correct.
>>
>> What's your feeling about this?
>
> I think this is going to be something we want eventually, but it's
> harder than I thought, so I won't pursue this for now.

Okay, lets keep it in mind for the future.

Thanks

  Andrea