0.8.5.3:

[sbcl.git] / src / cold / ansify.lisp

diff --git a/src/cold/ansify.lisp b/src/cold/ansify.lisp
index 31cf9fb..006a0df 100644 (file)
--- a/src/cold/ansify.lisp
+++ b/src/cold/ansify.lisp
@@ -1,4 +1,4 @@
-;;;; patches to hide some implementation idiosyncrasies in our
+;;;; patches to work around implementation idiosyncrasies in our
 ;;;; cross-compilation host
 
 ;;;; This software is part of the SBCL system. See the README file for
@@ -9,31 +9,14 @@
 ;;;; public domain. The software is in the public domain and is
 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
 ;;;; files for more information.
+\f
+;;;; CLISP issues
 
 #+clisp
-(locally
-
-  (in-package "COMMON-LISP")
-
-  ;; no longer needed in CLISP 1999-01-08, hurrah!
-  #|
-  ;; ANSI specifies that package LISP defines the type BOOLEAN, and the CMU CL
-  ;; compiler uses it a lot. This should be trivial to patch in CLISP, except
-  ;; that CLISP defines FFI:BOOLEAN, which conflicts. Gads.. Here we try to fix
-  ;; it with some package hacking. (Please do not take this as an example of
-  ;; good package hacking, I just messed with it until it seemed to work well
-  ;; enough to bootstrap CMU CL, because I'm highly unmotivated to make elegant
-  ;; fixes for nonstandard behavior. -- WHN)
-  (shadow 'ffi:boolean "FFI")
-  (deftype cl::boolean () '(member t nil))
-  (export 'boolean "LISP")
-  |#
-
-  ;; I gave up on using CLISP-1999-01-08 as a cross-compilation host because of
-  ;; problems that I don't have workarounds for:
-  (error "can't use CLISP -- no MAKE-LOAD-FORM")
-  (error "can't use CLISP -- no (FUNCTION (SETF SYMBOL-FUNCTION))")
-  )
+(ext:without-package-lock ("SYSTEM")
+  (setf system::*inhibit-floating-point-underflow* t))
+\f
+;;;; CMU CL issues
 
 ;;; CMU CL, at least as of 18b, doesn't support PRINT-OBJECT. In
 ;;; particular, it refuses to compile :PRINT-OBJECT options to
@@ -63,6 +46,28 @@
   (warn "CMU CL has a broken implementation of READ-SEQUENCE.")
   (pushnew :no-ansi-read-sequence *features*))
 
+#+(and cmu alpha)
+(unless (ignore-errors (read-from-string "1.0l0"))
+  (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".  Patch your core file~%~%"))
+
+#+(and cmu sparc)
+(ext:set-floating-point-modes :traps '(:overflow :invalid :divide-by-zero))
+\f
+;;;; OpenMCL issues
+#+openmcl 
+(unless (ignore-errors (funcall (constantly t) 1 2 3)) 
+  (error "please find a binary that understands CONSTANTLY to build from"))
+
+\f
+;;;; general non-ANSI-ness
+
+(in-package :sb-cold)
+
+(defmacro munging-cl-package (&body body)
+  #-clisp `(progn ,@body)
+  #+clisp `(ext:without-package-lock ("CL")
+            ,@body))
+
 ;;; Do the exports of COMMON-LISP conform to the standard? If not, try
 ;;; to make them conform. (Of course, ANSI says that bashing symbols
 ;;; in the COMMON-LISP package like this is undefined, but then if the
@@ -79,13 +84,16 @@
             (declare (ignore value))
             (unless (gethash key standard-ht)
               (warn "removing non-ANSI export from package CL: ~S" key)
-              (unexport (intern key cl) cl)))
+              (munging-cl-package
+               (unexport (intern key cl) cl))))
           host-ht)
   (maphash (lambda (key value)
             (declare (ignore value))
             (unless (gethash key host-ht)
               (warn "adding required-by-ANSI export to package CL: ~S" key)
-              (export (intern key cl) cl))
+              (munging-cl-package 
+               (export (intern key cl) cl)))
+            
             ;; FIXME: My righteous indignation below was misplaced. ANSI sez
             ;; (in 11.1.2.1, "The COMMON-LISP Package") that it's OK for
             ;; COMMON-LISP things to have their home packages elsewhere.
@@ -121,8 +129,3 @@
                       cl)
                 (kernel:%set-symbol-package symbol cl))))
           standard-ht))
-
-#+(and cmu alpha)
-(unless (ignore-errors (read-from-string "1.0l0"))
-  (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".  Patch your core file~%~%"))
-