I think you may be remembering an intention to implement that. The issue came up in 2009 (before the byte-compiler even caught the error), and there's only the initial patch you committed to signal the error: https://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/emacs-lisp/bytecomp.el?id=8476cfaf3dadf04379fde65cd7e24820151f78a9 and one more changing a variable name: https://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/emacs-lisp/bytecomp.el?id=d9bbf40098801a859f4625c4aa7a8cbe99949705 so lines 954-961 of bytecomp.el still read: (dolist (bytes-tail patchlist) (setq pc (caar bytes-tail)) ; Pick PC from goto's tag. ;; Splits PC's value into 2 bytes. The jump address is ;; "reconstructed" by the `FETCH2' macro in `bytecode.c'. (setcar (cdr bytes-tail) (logand pc 255)) (setcar bytes-tail (ash pc -8)) ;; FIXME: Replace this by some workaround. (or (<= 0 (car bytes-tail) 255) (error "Bytecode overflow"))) I mainly quote this to say: see what I mean about losing starting off as putting aside temporarily? :-) I sent in the bug report. On Tue, Jun 14, 2022 at 8:23 AM Stefan Monnier wrote: > > Or, you could just create a vector with one thunk for each package and > > loop through it invoking each one. It wouldn't be as space > > efficient, but it would be trivially correct. > > IIRC the compiler has code to split a bytecode object into two to try > and circumvent the 64k limit and it should definitely be applicable here > (it's more problematic when it's inside a loop), which is why I think > it's a plain bug. > > > Stefan > >