| 2021-11-24 13:43:39 |
Paul F. Dietz |
description |
Some issue in dead code elimination.
IN SBCL 2.1.10.214-c78c677a3, x86-64
(defun bug073 ()
(flet ((%f5 ()
(flet ((%f2 (&optional (f2-2 (return-from %f5 1)))
0))
(case f5-2
((1) (%f2))
((2) (%f2))
(t 0)))))
0))
==>
failed AVER:
(NOT
(AND (NULL (SB-C::BLOCK-SUCC SB-C::B))
(NOT (SB-C::BLOCK-DELETE-P SB-C::B))
(NOT
(EQ SB-C::B
(SB-C::COMPONENT-HEAD
(SB-C::BLOCK-COMPONENT SB-C::B))))))
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]
[...]
0: (SB-C::DELETE-BLOCK #<SB-C::CBLOCK NIL :START c1 {1021438F23}> NIL)
1: (SB-C::CLEAN-COMPONENT #<SB-C:COMPONENT :NAME (SB-C::INITIAL-COMPONENT BUG073) :REANALYZE T {1021436153}> NIL)
2: (SB-C::LOCALL-ANALYZE-CLAMBDAS-UNTIL-DONE (#<SB-C::CLAMBDA :%SOURCE-NAME SB-C::.ANONYMOUS. :%DEBUG-NAME (SB-C::TL-XEP BUG073) :KIND :EXTERNAL :TYPE #<SB-KERNEL:BUILT-IN-CLASSOID FUNCTION (read-only)> ..
3: (SB-C::%COMPILE (SB-INT:NAMED-LAMBDA BUG073 NIL (BLOCK BUG073 (FLET # 0))) #<SB-C::CORE-OBJECT {1021435A23}> :NAME NIL :PATH (SB-C::ORIGINAL-SOURCE-START 0 0))
[...] |
Some issue in dead code elimination.
IN SBCL 2.1.10.214-c78c677a3, x86-64
(still fails in SBCL SBCL 2.1.10.217-6c7f2a2d0, x86-64)
(defun bug073 ()
(flet ((%f5 ()
(flet ((%f2 (&optional (f2-2 (return-from %f5 1)))
0))
(case f5-2
((1) (%f2))
((2) (%f2))
(t 0)))))
0))
==>
failed AVER:
(NOT
(AND (NULL (SB-C::BLOCK-SUCC SB-C::B))
(NOT (SB-C::BLOCK-DELETE-P SB-C::B))
(NOT
(EQ SB-C::B
(SB-C::COMPONENT-HEAD
(SB-C::BLOCK-COMPONENT SB-C::B))))))
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]
[...]
0: (SB-C::DELETE-BLOCK #<SB-C::CBLOCK NIL :START c1 {1021438F23}> NIL)
1: (SB-C::CLEAN-COMPONENT #<SB-C:COMPONENT :NAME (SB-C::INITIAL-COMPONENT BUG073) :REANALYZE T {1021436153}> NIL)
2: (SB-C::LOCALL-ANALYZE-CLAMBDAS-UNTIL-DONE (#<SB-C::CLAMBDA :%SOURCE-NAME SB-C::.ANONYMOUS. :%DEBUG-NAME (SB-C::TL-XEP BUG073) :KIND :EXTERNAL :TYPE #<SB-KERNEL:BUILT-IN-CLASSOID FUNCTION (read-only)> ..
3: (SB-C::%COMPILE (SB-INT:NAMED-LAMBDA BUG073 NIL (BLOCK BUG073 (FLET # 0))) #<SB-C::CORE-OBJECT {1021435A23}> :NAME NIL :PATH (SB-C::ORIGINAL-SOURCE-START 0 0))
[...] |
|
