bug#54990: closed (Byte compiler bug)

[GNU bug Tracking System]

Your message dated Mon, 18 Apr 2022 10:48:43 +0000
with message-id <Yl1CCxxxwpCt3nIJ@ACM>
and subject line Re: bug#54990: Byte compiler bug
has caused the debbugs.gnu.org bug report #54990,
regarding Byte compiler bug
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
54990: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=54990
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
> --- Begin Message ---
>
>
>
> Subject: 
>
> Byte compiler bug
>
>
>
>
> Date: 
>
> Sun, 17 Apr 2022 12:31:16 +0000
>
>
>
>
> Hello, Emacs.
>
> In up to date master branch:
> (i) emacs -Q
> (ii) Enter the following into buffer *scratch*:
>
>     (defun E+->E@+ (elt op)
>       (cond
>        ((eq op '+) (setcar elt '*))
>        ((eq op '+\?) (setcar elt '*\?))))
>     (defconst foo-elt '(+\? . "foo"))
>     (E+->E@+ foo-elt '+\?)
>
>   .
> (iii) With point in the defun, M-x compile-defun.
> (iv) Evaluate the defconst.
> (v) Evaluate the E+->E@+ form.
> (vi) M-: foo-elt.  It's value is unchanged from its declaration.  It
>   should have been changed to (*\? . "foo").  This is a bug.
>
> (vii) M-x disassemble RET E+->E@+.  Instead of working, this gives the
>   error message:
>
>     Optimizer error: missed tags (((TAG 2) TAG 4) ((TAG 1) TAG 3))
>
>   .  This is a bug.
>
> (viii) (Optional)  Evaluate the defun form with C-M-x, and evaluate the
>   E+->E@+ form.  M-: foo-elt.  This shows the expected value,
>   (*? . "foo").
>
> At a guess, the symbols with the \? in their names have something to do
> with the bug.
>
> Here is my configuration:
>
> In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
> 3.24.31, cairo version 1.16.0)
>  of 2022-04-17 built on ACM
> Repository revision: 2136db067f4292d84553ebfddab30d88b862262e
> Repository branch: master
> System Description: Gentoo/Linux
>
> Configured using:
>  'configure --with-gif=no --with-tiff=no --with-gpm
>  --with-native-compilation'
>
> Configured features:
> ACL CAIRO DBUS FREETYPE GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
> LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG
> SECCOMP SOUND SQLITE3 THREADS TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XPM
> GTK3 ZLIB
>
> -- 
> Alan Mackenzie (Nuremberg, Germany).
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#54990: Byte compiler bug
>
>
>
>
> Date: 
>
> Mon, 18 Apr 2022 10:48:43 +0000
>
>
>
>
> Hello, Mattias.
>
> On Sun, Apr 17, 2022 at 16:32:53 +0200, Mattias Engdegård wrote:
> > This is related to symbol positioning so Alan should be well-placed to
> > debug it. (The symbol names are irrelevant.)
>
> I'd got just as far as identifying the merge of
> scratch/correct-warning-pos as the first version containing the bug.
>
> > It's `compile-defun` that is broken; the constant vector of the
> > resulting bytecode contains symbols with position as hash table keys
> > for a switch operation. Compare the bytecode object with that from
> > `byte-compile` which works correctly:
>
> Thank you for this observation.  It was _exceptionally_ helpful.
>
> > (defun tata (x)
> >   (cond
> >    ((eq x 'a) 'toto)
> >    ((eq x 'b) 'titi)))
>
> > (byte-compile 'tata)
> > =>
> > #[257 "..." [#s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 
> > 0.8125 purecopy t data (a 6 b 8)) toto titi nil] 3 "..."]
>
> > ;; if using `compile-defun` on `tata`:
> > (symbol-function 'tata)
> > #[257 "..." [#s(hash-table size 2 test eq rehash-size 1.5 rehash-threshold 
> > 0.8125 purecopy t data (#<symbol a at 293> 6 #<symbol b at 314> 8)) toto titi 
> > nil] 3 "..."]
>
> I've committed a fix, which I'm pretty sure works, so I'm closing the bug
> with this post.  Thanks again for the help!
>
> -- 
> Alan Mackenzie (Nuremberg, Germany).
>
>
> --- End Message ---