AVER, MEMQ ... END-STACK failure

[Paul F. Dietz]

Perhaps related to 1722342.

Found with random tester. Two failures were found, which may or may not be related. I have included both.

(defun f3 (x)
  (block b1
    (multiple-value-prog1 0
      (block b2 (return-from b1 (catch 'c (return-from b2 x)))))))

debugger invoked on a SB-INT:BUG in thread
#<THREAD "main thread" RUNNING {100192EAB3}>:
    failed AVER: (NOT (SB-INT:MEMQ PUSH SB-C::END-STACK))

-------------

(defun f4 ()
  (block b1
    (multiple-value-prog1 0
      (tagbody
         (return-from b1 (return-from b1 (catch 'ct8 (go tag4))))
       tag4))))

debugger invoked on a SB-INT:BUG in thread
#<THREAD "main thread" RUNNING {100192EAB3}>:
    failed AVER: (NOT (SB-INT:MEMQ PUSH SB-C::END-STACK))

[Alastair Bridgewater (alastair-bridgewater)]

These two failures, yes, are related to each other. One of them is virtually identical to the case reported on the mailing list on the 29th of March this year.

In both cases, what's happening is that MAYBE-DELETE-EXIT is deleting an EXIT with no value semantics (either because it's a TAGBODY/GO or because it's returning to a block whose value is simply being ignored), removing it from the ENTRY. From there, MAY-DELETE-VESTIGIAL-EXIT sees that the ENTRY has no EXITs leading to it, and thus decides that there won't be any cleanup code generated for it, which turns out not to be the case.

Test cases added to compiler.pure.lisp in 9acc615ae49d6faefe7e5a83216c1215be18f858, because we might as well do it now, even if we don't have a fix yet.

As a side note, it appears as though ONLY-HARMLESS-CLEANUPS, as used by MAYBE-CONVERT-TAIL-LOCAL-CALL, will make the same determination with respect to cleanup code generation, which suggests that there may be a bug there as well.

[Stas Boukarev (stassats)]

075379540c89dc348d4b93c63598fee4ca1f99fe