Skip to content
Snippets Groups Projects
  1. Feb 04, 2005
  2. Feb 03, 2005
  3. Feb 02, 2005
  4. Feb 01, 2005
  5. Jan 31, 2005
  6. Jan 29, 2005
  7. Jan 27, 2005
  8. Jan 25, 2005
  9. Jan 13, 2005
  10. Jan 07, 2005
    • rtoy's avatar
      This function from the misc.492 test from ansi-tests: · 529a9ff2
      rtoy authored
      (defun fn-492 (r p1)
        (declare (optimize speed (safety 1))
      	   (type (simple-array (signed-byte 8) nil) r) (type (integer * 22050378) p1))
        (setf (aref r) (lognand (the (integer 19464371) p1) 2257))
        (values))
      
      confuses the compiler and causes (values) to be deleted, and also
      deletes the return from the function so we just run past the end into
      junk.
      
      I think it's caused by confusion in type derivation.  I changed the
      defoptimizer for %aset so it returns the specialized element-type of
      the array instead of the new-value.
      
      This is a workaround, not a solution.
      529a9ff2
  11. Jan 06, 2005
  12. Dec 24, 2004
    • rtoy's avatar
      From Helmut Eller, cmucl-imp, 2004-10-05: · 627128ba
      rtoy authored
          on Linux/x86, the Lisp signal handler for SIGSEGV overwrites the
          beginning of the control stack.
      
          For SIGSEGV we use an extra signal stack and when the signal isn't
          handled by the GC or by the stack overflow handler we call eventually
          call_into_lisp.  call_into_lisp tests whether the current stack
          pointer points to the normal control stack.  But the test fails
          because we use the extra signal stack, so call_into_lisp just sets the
          stack pointer to the beginning of the normal control stack. This is
          not much fun for debugging because the backtrace is truncated and it's
          also no longer possible to throw to the top-level-catcher because its
          frame was overwritten.
      
          I tried to fix that with the patch below.  The idea is to switch back
          to the normal stack before calling the Lisp handler.  The patch may
          not be very elegant but it is at least short  :) .
      627128ba
    • rtoy's avatar
      Export CALLBACK-FUNCALL and document it. · c2d59248
      rtoy authored
      c2d59248
  13. Dec 23, 2004
  14. Dec 22, 2004
  15. Dec 21, 2004
  16. Dec 17, 2004
  17. Dec 16, 2004
    • rtoy's avatar
      Enable loop analysis code. But the default is loop analysis is not · be26c9f9
      rtoy authored
      done, because we don't do anything with the loop results.
      
      ir1util.lisp:
      	o Make sure component initializes the outer-loop slot of the
      	  component.
      
      main.lisp:
      	o Add defvar *loop-analyze*, defaulting to NIL.
      	o Run loop analysis code when *loop-analyze* is T.
      
      node.lisp:
      	o Make the outer-loop slot of a component a required arg and
      	  adjust the declared type appropriately.
      
      represent.lisp:
      	o Add ASSIGN-TN-DEPTHS function to assign loop depths to TNs.
      
      vop.lisp:
      	o Forgot to add the loop-depth slot for TNs.
      be26c9f9
  18. Dec 15, 2004
  19. Dec 14, 2004
  20. Dec 13, 2004
  21. Dec 09, 2004
Loading