Fix make-array transforms.
[sbcl.git] / src / cold / ansify.lisp
1 ;;;; patches to work around implementation idiosyncrasies in our
2 ;;;; cross-compilation host
3
4 ;;;; This software is part of the SBCL system. See the README file for
5 ;;;; more information.
6 ;;;;
7 ;;;; This software is derived from the CMU CL system, which was
8 ;;;; written at Carnegie Mellon University and released into the
9 ;;;; public domain. The software is in the public domain and is
10 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
11 ;;;; files for more information.
12 \f
13 ;;;; CLISP issues
14
15 ;;; as explained on #lisp ca. October 2003:
16 ;;;   <Krystof> chandler: nope, I'm blaming another clisp bug
17 ;;;   <Krystof> [8]> least-positive-short-float
18 ;;;   <Krystof> 2.93874s-39
19 ;;;   <Krystof> [9]> (coerce * 'single-float)
20 ;;;   <Krystof> 0.0
21 ;;;   <chandler> aah
22 ;;;   <mwh> "oops"
23 ;;;   <Krystof> yep
24 ;;;   <mwh> tried that on clisp from fink:
25 ;;;   <mwh> [1]> least-positive-short-float
26 ;;;   <mwh> 2.93874s-39
27 ;;;   <mwh> [2]> (coerce * 'single-float)
28 ;;;   <mwh> *** - floating point underflow
29 ;;;   <Krystof> yeah
30 ;;;   <mwh> shall i not try to build sbcl with that?
31 ;;;   <Krystof> if you turn off underflow traps, then you get 0.0
32 ;;;   <mwh> well, that makes sense, i guess
33 ;;;   <Krystof> #+clisp
34 ;;;   <Krystof> (ext:without-package-lock ("SYSTEM")
35 ;;;   <Krystof>   (setf system::*inhibit-floating-point-underflow* t))
36 ;;;   <Krystof> (in src/cold/ansify.lisp)
37 #+clisp
38 (ext:without-package-lock ("SYSTEM")
39   (setf system::*inhibit-floating-point-underflow* t))
40 \f
41 ;;;; CMU CL issues
42
43 ;;; CMU CL, at least as of 18b, doesn't support PRINT-OBJECT. In
44 ;;; particular, it refuses to compile :PRINT-OBJECT options to
45 ;;; DEFSTRUCT, so we need to conditionalize such options on the
46 ;;; :NO-ANSI-PRINT-OBJECT feature in order to get the code to compile.
47 ;;; (It also fails to do anything useful with DEFMETHOD PRINT-OBJECT,
48 ;;; but that doesn't matter much, since it doesn't stop the
49 ;;; cross-compiler from working.)
50 #+cmu
51 (progn
52   (warn "CMU CL doesn't support the :PRINT-OBJECT option to DEFSTRUCT.~%")
53   (pushnew :no-ansi-print-object *features*))
54
55 ;;; KLUDGE: In CMU CL, at least as of 18b, READ-SEQUENCE is somewhat
56 ;;; dain-bramaged. Running
57 ;;;   (defvar *buffer* (make-array (expt 10 6) :element-type 'character))
58 ;;;   (with-open-file (s "/tmp/long-file.tmp")
59 ;;;     (/show (read-sequence *buffer* s :start 0 :end 3000))
60 ;;;     (/show (read-sequence *buffer* s :start 0 :end 15000))
61 ;;;     (/show (read-sequence *buffer* s :start 0 :end 15000)))
62 ;;; on a large test file gives
63 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 3000)=3000
64 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=1096
65 ;;; /(READ-SEQUENCE *BUFFER* S :START 0 :END 15000)=0
66 #+cmu
67 (progn
68   (warn "CMU CL has a broken implementation of READ-SEQUENCE.")
69   (pushnew :no-ansi-read-sequence *features*))
70
71 ;;; This is apparently quite old, according to
72 ;;; <http://tunes.org/~nef/logs/lisp/03.10.22>:
73 ;;;   <dan`b> (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".
74 ;;;   <dan`b> the warning relates to a random vinary produced from cvs of
75 ;;;           around feb 2000, the corresponding sources to which I never found
76 ;;; (But it seems harmless to leave it here forever just in case.)
77 #+(and cmu alpha)
78 (unless (ignore-errors (read-from-string "1.0l0"))
79   (error "CMUCL on Alpha can't read floats in the format \"1.0l0\".  Patch your core file~%~%"))
80
81 #+(and cmu sparc)
82 (ext:set-floating-point-modes :traps '(:overflow :invalid :divide-by-zero))
83 \f
84 ;;;; OpenMCL issues
85
86 ;;; This issue in OpenMCL led to some SBCL bug reports ca. late 2003.
87 #+openmcl
88 (unless (ignore-errors (funcall (constantly t) 1 2 3))
89   (error "please find a binary that understands CONSTANTLY to build from"))
90 \f
91 ;;;; general non-ANSI-ness
92
93 (in-package :sb-cold)
94
95 (defmacro munging-cl-package (&body body)
96   #-clisp `(progn ,@body)
97   #+clisp `(ext:without-package-lock ("CL")
98              ,@body))
99
100 ;;; Do the exports of COMMON-LISP conform to the standard? If not, try
101 ;;; to make them conform. (Of course, ANSI says that bashing symbols
102 ;;; in the COMMON-LISP package like this is undefined, but then if the
103 ;;; host Common Lisp were ANSI, we wouldn't be doing this, now would
104 ;;; we? "One dirty unportable hack deserves another.":-)
105 (let ((standard-ht (make-hash-table :test 'equal))
106       (host-ht     (make-hash-table :test 'equal))
107       (cl         (find-package "COMMON-LISP")))
108   (do-external-symbols (i cl)
109     (setf (gethash (symbol-name i) host-ht) t))
110   (dolist (i (read-from-file "common-lisp-exports.lisp-expr"))
111     (setf (gethash i standard-ht) t))
112   (maphash (lambda (key value)
113              (declare (ignore value))
114              (unless (gethash key standard-ht)
115                (warn "removing non-ANSI export from package CL: ~S" key)
116                (munging-cl-package
117                 (unexport (intern key cl) cl))))
118            host-ht)
119   (maphash (lambda (key value)
120              (declare (ignore value))
121              (unless (gethash key host-ht)
122                (warn "adding required-by-ANSI export to package CL: ~S" key)
123                (munging-cl-package
124                 (export (intern key cl) cl)))
125
126              ;; FIXME: My righteous indignation below was misplaced. ANSI sez
127              ;; (in 11.1.2.1, "The COMMON-LISP Package") that it's OK for
128              ;; COMMON-LISP things to have their home packages elsewhere.
129              ;; For now, the hack below works, but it's not good to rely
130              ;; on this nonstandardness. Ergo, I should fix things so that even
131              ;; when the cross-compilation host COMMON-LISP package has
132              ;; symbols with home packages elsewhere, genesis dumps out
133              ;; the correct stuff. (For each symbol dumped, check whether it's
134              ;; exported from COMMON-LISP, and if so, dump it as though its
135              ;; home package is COMMON-LISP regardless of whether it actually
136              ;; is. I think..)
137              ;;
138              ;; X CMU CL, at least the Debian versions ca. 2.4.9 that I'm
139              ;; X using as I write this, plays a sneaky trick on us by
140              ;; X putting DEBUG and FLOATING-POINT-INEXACT in the
141              ;; X EXTENSIONS package, then IMPORTing them into
142              ;; X COMMON-LISP, then reEXPORTing them from COMMON-LISP.
143              ;; X This leaves their home packages bogusly set to
144              ;; X EXTENSIONS, which confuses genesis into thinking that
145              ;; X the CMU CL EXTENSIONS package has to be dumped into the
146              ;; X target SBCL. (perhaps a last-ditch survival strategy
147              ;; X for the CMU CL "nooo! don't bootstrap from scratch!"
148              ;; X meme?) As far as I can see, there's no even slightly
149              ;; X portable way to undo the damage, so we'll play the "one
150              ;; X dirty unportable hack deserves another" game, only even
151              ;; X dirtierly and more unportably than before..
152              #+cmu
153              (let ((symbol (intern key cl)))
154                (unless (eq (symbol-package symbol) cl)
155                  (warn "using low-level hack to move ~S from ~S to ~S"
156                        symbol
157                        (symbol-package symbol)
158                        cl)
159                  (kernel:%set-symbol-package symbol cl))))
160            standard-ht))