m-v-b: bug in the compiler

Problem is present in 13.5.1 as well.

Snippet:

% cat test.lisp
(defvar v1 nil)

(defun run-test ()
  (let ((share_t)
        (fst 'a))
    (format t "fst ~S~%" fst)
    (multiple-value-bind (v1 fst)
        (case share_t
          ((nil)
           (values v1 fst)))
      (format t "fst ~S~%" fst))))

% ecl
ECL (Embeddable Common-Lisp) 16.1.2 (git:UNKNOWN)
Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
Copyright (C) 1993 Giuseppe Attardi
Copyright (C) 2000 Juan J. Garcia-Ripoll
Copyright (C) 2015 Daniel Kochmanski
ECL is free software, and you are welcome to redistribute it
under certain conditions; see file 'Copyright' for details.
Type :h for Help.  
Top level in: #<process TOP-LEVEL>.
> (compile-file "test.lisp")

;;; Loading #P"/u/gildea/lib/ecl-16.1.2/cmp.fas"
;;;
;;; Compiling test.lisp.
;;; OPTIMIZE levels: Safety=2, Space=0, Speed=3, Debug=0
;;;
;;; Compiling (DEFVAR V1 ...).
;;; Compiling (DEFUN RUN-TEST ...).
;;; End of Pass 1.
;;; Emitting code for RUN-TEST.
;;; Finished compiling test.lisp.
;;;
#P"/tmp/test.fas"
NIL
NIL
> (load "test.fas")

;;; Loading "/tmp/test.fas"
#P"/tmp/test.fas"
> (run-test)
fst A
fst NIL
NIL
> (run-test)
fst A
fst A
NIL
> 

Reported by Dan Gildea

changed milestone to %ECL 16.2.0

changed the description

Even smaller example to reproduce:

(defvar v1 'booya)
(defun run-test8 ()
  (let ((share_t))
    (multiple-value-bind (v1 woops)
        (case share_t
          ((nil)
           (values 1 2)))
      (print woops))))

bind-or-set in cmpmulti

;; We know that at least MIN-VALUES variables will get a value
    (wt-nl "printf(\"nvalues[1.4] = %d\\\n\", cl_env_copy->nvalues);")
    (dotimes (i min-values)
      (when vars
        (let ((v (pop vars))
              (loc (values-loc-or-value0 i)))
          (wt-nl "printf(\"nvalues[1.45] = %d\\\n\", cl_env_copy->nvalues);")
          (bind-or-set loc v use-bind))))

resets nvalues to 0 on first run, what causes the issue. Investigating.

(bind loc v) from bind-or-set

problem is caused in bds-bind which calls ecl_bds_bind(cl_env_copy,VV[0],value0); which resets nvalues. not sure why and exactly where yet. Second invocation doesn't have this error. Not sure why yet.

it seems that invalid_or_too_large_binding_index(env,s); may reset nvalues. (env pointer doesn't lose its identity).

si_set_finalizer changes nvalues to 0, becaue it calls @(return)

assigned to @jackdaniel

closed via merge request !77 (merged)