* Most of the failures were test that cannot pass due to missing bits of DX implementation -- stack allocatable vectors and fixed-alloc. * Mark backtrace test 353 as expected to fail on PPC as well. * Don't declare *HANDLER-CLUSTERS* as dynamic-extent on platforms that do not support DX fixed-alloc, since it will just give a spurious compiler note.
* The problem has been there since 188.8.131.52, but possibly exposed only recently: MOVE-IF/CHAR cannot use byte-sized registers since CMOV cannot. Hence disable if for non-unicode builds. Reported by Stas Boukarev. * Missing news entry from 184.108.40.206.
* Delete SUPPORT and minimize BUGS. The information that used to be there is now the first chapter of the manual: "Getting Support and Reporting Bugs", Maybe it belongs elsewhere, but IMO it should be as prominent as we can make it - so the first chapter for now. Refer to Lauchpad and sbcl-bugs in "Reporting Bugs". Remove Dan B. from support providers for now, given that metacircles.com is currently domain-parked.
* This has been around for a while, but despite the misleading comment in the source the spec is clear enough.
* from 220.127.116.11: when destructuring a constant :INITIAL-CONTENTS to MAKE-ARRAY, take care to quote the elements. * from 18.104.22.168: handle :BACK and :UP in CANONICALIZE-PATHNAME, and make sure they do not appear after :WILD-INFERIORS or :ABSOLUTE. I'm more and more concinved that MAKE-PATHNAME should canonicalize, though, so that these checks don't need to be carried out by users of pathnames -- but leaving that for later. ...how appropriate that it is .71 that fixes both.
* Patch and test-case by Stas Boukarev.
* FILE-AUTHOR returns NIL instead of signalling an error on Windows * Missing DIRECTORY canonicalization tests. * Check one-letter devices for being alpha-chars when unparsing them on Windows. * NATIVE-NAMESTRING now has similar tailing-slash handling on Windows as elsewhere -- adjust the test. * Windows namestrings canonicalize / to \ -- make the random namestring tests take that into account. ...filesys.pure.lisp passes on Windows.
nyef pointed out that compiler/generic/array.lisp was kinda ugly with the #!+ condition goo it in. This patch is the first step towards moving all backends over to the slimmer EMIT-ERROR-BREAK interface--one that doesn't require duplicating lots of error generation code in VOP generation functions.
* On unixoid platforms is this pretty much what UNIX-GETTIMEOFDAY used to be, whereas on Windows we build it on top of SystemTimeAsFileTime since gettimeofday() doesn't give us microseconds there -- it's almost as if the POSIX API support on Windows as intentionally sucky... * Keep UNIX-GETTIMEOFDAY around as a wrapper to GET-TIME-OF-DAY, since there are applications in the wild that use it directly. Scheduled for deletion towards to the end of 2009, or so.
We were trying to set the PROBES/MISSES variables prior to actually defining them. Rearrange the logic and add a little OAOO to ensure the variables are DEFVAR'd first.
* While DIRECTORY on local UNC paths worked as of 22.214.171.124, turns out Windows network shares don't exist as far as stat() is concerned -- and hence using the proper share path didn't work. Replace QUERY-FILE-SYSTEM in MAP-DIRECTORY with UNIX-REALPATH sans stat, and we're good. * Canonicalize the pathnames for DIRECTORY, so that (DIRECTORY #P".") is equivalent to (DIRECTORY #P"./") -- ditto for #P".." and #P"../". Also make DIRECTORY treat :UNSPECIFIC names and types as if they were NIL.
* Based on old SB-INT:DEFINE-HASH-TABLE-TEST, but: ** macro, not a function. ** only two arguments: name of the test function, and the hash function (which can also be a lambda form.) ** :TEST accepts both 'NAME, and #'NAME as well. ** pick up redefinitions of the test and hash-function without re-executing the D-H-T-T form. ** protected by package locks. * MAKE-HASH-TABLE :HASH-FUNCTION supported as well. EQ-based hashing not legal for user-provided hash functions, accidents prevented by wrapping functions which may return a true secondary value in a closure. * Documentation -- other hash-table extensions as well. * Documentation generation improvements: ** use the shortest package name available -- CL:FOO, not COMMON-LISP:FOO. ** kludge around texi2pdf making &key and company bold ** add exceptions so that we don't format words ANSI and CLHS as lowecase symbols.
Apparently there were other clients floating out in the wild.
* Rip out !ENUMERATE-MATCHES, which insisted on walking the directory tree from the root -- making using DIRECTORY on UNC pathnames a losing proposition. * New guts built on top of MAP-DIRECTORY, and it's lower level cousin WITH-NATIVE-DIRECTORY-ITERATOR. This seems easier to understand to me at least, and was certainly easier than trying to re-architect !ENUMERATE-MATCHES. ...and DIRECTORY now works on UNC shares, yay! ...and a bunch of associated secondary changes: ** Rename UNIX-FILE-KIND NATIVE-FILE-KIND, and move it to filesys.lisp. ** Add functions UNIX-OPENDIR, UNIX-READDIR, UNIX-CLOSEDIR, and UNIX-DIRENT-NAME -- later to be turned into OS-*, and possibly moved into SB-SYS. ** *IGNORE-WILDCARDS* is no longer needed in MAYBE-MAKE-PATTERN, kill it. ** Share UNPARSE-*-PIECE as UNPARSE-PHYSICAL-PIECE between Win32 and Unix: both have the same lisp namestring syntax for pieces, and if a third pathname host appears it probably should too. ** Fix DEFKNOWN of DIRECTORY: RESOLVE-SYMLINKS needs to be a keyword there. ** Kill QUICK-INTEGER-TO-STRING -- use %OUTPUT-INTEGER-IN-BASE in GENSYM instead. ** Kill PATHAME-ORDER, unused. ** Follow the same convention as elsewhere for :AS-FILE in NATIVE-NAMESTRING on Windows -- users needing the no-trailing-slash version are supposed to say :AS-FILE. OS pickiness on slash-or-no seems universal...
UNC hosts are represented using the devíce components of pathnames, as are drives. This is sleightly lossy since it prevents accessing network hosts named with a single letter -- single-letter devices are taken to mean drives. However, since storing the host in the pathname host component would lead to confusion between logical hosts and UNC hosts, this seems preferable right now, so that (make-pathname :host "foo" ...) remains unambiguous. DIRECTORY does not work yet with UNC pathnames since it insists on walking the path from root -- which Windows doesn't seem to allow for UNC paths, not even local ones.
Consider (MAKE-ARRAY '(3) :INITIAL-CONTENTS (LIST X Y Z)): The transform for LIST dimensions replaces this with an identical call, except that the dimensions will be 3. The transform for INTEGER dimensions fires, but does not yet see the (LIST X Y Z) in INITIAL-CONTENTS, since it is now an argument to the lambda introduced by the previous call. One option would be to delay the latter transform if we don't see how to compile it nicely, because after a couple of IR1-OPTIMIZE passes the call to LIST will be there, and the intermediate lambda eliminated. However, because multiple roundtrips like that suck, instead make the source transform for MAKE-ARRAY smart enough to recognize this case, and transform to the integer argument case directly. ...now, this makes me think we really should try to eliminate / simplify lambdas introduced by TRANSFORM-CALL up front somehow.
...based on the type the host object will take in target, which just needs to follow the same logic our dumper uses. ...fixing which shows the the new FILL transform didn't handle complex single floats quite right yet.
Foreign code might not have a frame pointer like we expect. Use CONTROL-STACK-POINTER-VALID-P to check it. Patch by Bart Botta.
The performance boost for all cases which previously used VECTOR-FILL* is quite noticeable. Also delay the FILL transform if the vector element type is not yet known. ...also one leftover #+sb-xc-host from the previous commit.
Christophe points out that (UPGRADED-COMPLEX-PART-TYPE 'DOUBLE-FLOAT) can be REAL on some hosts, in which case the host will happily agree that (TYPEP #C(2 2) '(COMPLEX DOUBLE-FLOAT)) is true... etc. So in the cross compiler look at the type of the parts of the complex, and refuse to dump it if it doesn't look like something we can handle correctly.
* No reason to disable it that I can see, and if it is disabled the cross-compiler will dump slightly bogus objects for complex single and double floats -- using the generic complex widetag. Noticed while trying to initialize arrays using the SAETP-DEFAULT-INITIAL-ELEMENT.
* Add a source transform for MAKE-ARRAY that declaims LIST and VECTOR as NOTINLINE, so the the MAKE-ARRAY deftransforms are able to pick them apart (for DIMENSIONS and :INITIAL-CONTENTS.) * INITIALIZE-VECTOR is a new magic function with a IR2-CONVERT transform. It's purpose is to allow open coding :INITIAL-CONTENTS initialization without inhibiting stack allocation. * Turns out that making stack allocation decisions during locall analysis is not enough since optimization iterates: if a transform occurs and introduces new LVARs that would be good for DX after the locall analysis has run for the combination, the new LVARs will not get their share of stacky goodness. Therefore, after a transform propagate DX information to the new functional explicitly (see MAYBE-PROPAGATE-DYNAMIC-EXTENT.) * The new logic is in TRANSFORM-MAKE-ARRAY-VECTOR, which handles all the cases of vector allocation with a known element type: ** :INITIAL-CONTENTS (LIST ...), (VECTOR ...) and (BACKQ-LIST ...) are picked apart when the length matches the vector length, and their arguments are spliced into the call. Constant :INITIAL-CONTENTS is picked apart as well. Initialization is done using INITIALIZE-VECTOR. ** Otherwise :INITIAL-CONTENTS is splatted in place using REPLACE after we have checked that the length matches. ** :INITIAL-ELEMENT not EQL to the default element uses FILL. ** Otherwise the default initialization is fine. Some additional hair here, since MAYBE-PROPAGATE-DYNAMIC-EXTENT cannot deal with OPTIONAL-DISPATCH functionals. So to ensure we get full benefit of it, make sure the lambdas we transform to have only required arguments -- courtesy of new ELIMINATE-KEYWORD-ARGUMENT utility. (Note: it might be worth it to do something like this for many cases automatically, to reduce the number of lambdas the compiler generates. For inline lambdas we could do the whole &key handling _before_ the lambda is converted...) * Identify the case of (LIST N) as dimensions as being a vector, and delegate to TRANSFORM-MAKE-ARRAY-VECTOR. * More efficient allocation of simple multidimensional arrays in the presence of :INITIAL-CONTENTS (still slow, though) and :INITIAL-ELEMENT (not bad.) * Fix the source transform for VECTOR so that it too can stack allocate. * Updates tests and docs.
FUN-INFO-RESULT-ARG is either NIL, or the index of the argument that is EQ to the result of the function. Use LVAR-GOOD-FOR-DX-P with the argument lvar that is the result argument. Other arguments are for DX as well: if the result can be stack allocated then unless the other arguments are otherwise accessible they too can be stack allocated -- and if they are otherwise accessible then DX analysis should refuse to stack allocate.
* Assert the declared element-type in the HAIRY-DATA-VECTOR-(REF|SET)/CHECK-BOUNDS transform, since HAIRY-DATA-VECTOR-(REF|SET) transforms no longer fire for non-simple arrays. * Turns out that %DATA-VECTOR-AND-INDEX was the only place where the index was checked being non-negative on some code paths -- not taking that route meant that type check weakening from INDEX to FIXNUM allowed negative indexes to slip in under the the radar in SAFETY 1 code. While this follows what we say in the manual, being more careful about bounds checks is probably a good idea, so be more conservative about weakenin integer types: collapse unions of intervals into a single interval, but dont' eliminate the most extreme bounds. Adjust one test that checked for the old behaviour, and update documentation.
… element types The transforms for HAIRY-DATA-VECTOR-(REF|SET) which inserted a call to %DATA-VECTOR-AND-INDEX were never a win unless the array was known to be simple: the element type dispatch is quite effcient, and the slow path has an open coded WITH-ARRAY-DATA which performs better. For simple arrays the transforms remain a win, since %DATA-VECTOR-AND-INDEX will be open coded: at most one dereference is ever necessary. Unfortunately declaring the element type of a non-simple array remains a loss -- just a less drastic one then before.
Fixes problems with the floating point modes being forgotten. Also fixes one of the float tests by clearing the exception flags first, insuring that the right exception is raised. Patch by Josh Elsasser.
Also reduce OAOOMity of GET-MACHINE-VERSION. Patch by Josh Elsasser.