failed AVER: (SB-VM::GPR-TN-P SB-VM::X)

Bug #1888384 reported by Paul F. Dietz
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
SBCL
Fix Released
Undecided
Unassigned

Bug Description

(lambda ()
  (oddp (the (or (foo)
                 (bar))
             -1)))

;; where (foo) and (bar) are bogus type specifiers

==>

failed AVER: (SB-VM::GPR-TN-P SB-VM::X)
[...]
Backtrace:
  0: (SB-VM::EMIT-OPTIMIZED-TEST-INST #<SB-C:TN '-1!1 :CONSTANT> 2 NIL)
  1: (SB-C::GENERATE-CODE #<SB-C:COMPONENT :NAME (LAMBDA NIL) {1008962D13}>)
  2: (SB-C::%COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (LAMBDA NIL) {1008962D13}>)
  3: (SB-C::COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (LAMBDA NIL) {1008962D13}>)
[...]

Revision history for this message
Paul F. Dietz (paul-f-dietz) wrote :

Similar input that also fails, with a different error:

(compile nil '(lambda () (1- (the (or (foo) (bar)) 1))))

==>

Shouldn't have a load TN for arg0
This is probably a bug in SBCL itself. (Alternatively, SBCL
might have been corrupted by bad user code, e.g. by an undefined
Lisp operation like (FMAKUNBOUND 'COMPILE), or by stray pointers
from alien code or from unsafe Lisp code; or there might be a
bug in the OS or hardware that SBCL is running on.) If it seems
to be a bug in SBCL itself, the maintainers would like to know
about it. Bug reports are welcome on the SBCL mailing lists,
which you can find at <http://sbcl.sourceforge.net/>.
   [Condition of type SB-INT:BUG]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] abort thread (#<THREAD "new-repl-thread" RUNNING {1034C60DC3}>)

Backtrace:
  0: (SB-INT:BUG "Shouldn't have a load TN for arg0")
  1: (SB-VM::PREPARE-ALU-OPERANDS #<unused argument> #<SB-C:TN '1!1 :CONSTANT> 2 #<SB-C::VOP :INFO SB-VM::FAST---C/FIXNUM=>FIXNUM :ARGS #<SB-C:TN-REF :TN #<SB-C:TN '1!1 :CONSTANT> :WRITE-P NIL :VOP SB-VM::..
  2: (SB-VM::EMIT-INLINE-ADD-SUB SB-VM::SUB #<unavailable argument> #<unavailable argument> #<SB-C:TN t2[RDX] :NORMAL> #<SB-C::VOP :INFO SB-VM::FAST---C/FIXNUM=>FIXNUM :ARGS #<SB-C:TN-REF :TN #<SB-C:TN '1!..
  3: (SB-C::GENERATE-CODE #<SB-C:COMPONENT :NAME (LAMBDA NIL) {1034C829C3}>)
  4: (SB-C::%COMPILE-COMPONENT #<SB-C:COMPONENT :NAME (LAMBDA NIL) {1034C829C3}>)

Stas Boukarev (stassats)
Changed in sbcl:
status: New → Confirmed
Revision history for this message
Paul F. Dietz (paul-f-dietz) wrote :

Another example, with yet another error message. Probably the same bug.

(defun bug020 ()
  (logbitp 20 (the (or (foo) (bar)) 1)))

==>

SB-VM::IMMEDIATE-CONSTANT fell through ECASE expression.
Wanted one of (SB-VM::STACK SB-KERNEL:CONSTANT).
   [Condition of type SB-KERNEL:CASE-FAILURE]

Restarts:
 0: [RETRY] Retry SLIME REPL evaluation request.
 1: [*ABORT] Return to SLIME's top level.
 2: [ABORT] abort thread (#<THREAD "new-repl-thread" RUNNING {103DDEC393}>)

Backtrace:
  0: (SB-X86-64-ASM::EMIT-EA #<SB-ASSEM:SEGMENT {103DF94D53}> #<SB-C:TN '1!1 :CONSTANT> 4 :REMAINING-BYTES 0 :XMM-INDEX NIL)
  1: ((FLET SB-X86-64-ASM::EMIT* :IN "SYS:SRC;COMPILER;X86-64;INSTS.LISP") #<SB-ASSEM:SEGMENT {103DF94D53}> :DWORD #<SB-C:TN '1!1 :CONSTANT> 20 NIL 4)
  2: (SB-ASSEM::%ASSEMBLE #<SB-ASSEM:SEGMENT {103DF94D53}> (#<SB-ASSEM::STMT IGNORE {103DF92543}> . #<SB-ASSEM::STMT .ALIGN {103DF94F13}>))

Stas Boukarev (stassats)
Changed in sbcl:
status: Confirmed → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.