Steel Bank Common Lisp

On Tue, Mar 26, 2002 at 08:46:42AM -0500, Nathan Froyd wrote:
> ANSI-compliant and includes a small ANSIfication in grovel-headers.c.  I

Thanks for this -- most of it is great, but there's a small problem that
I'm seeing:

-    printf("(define-alien-type "##lispname##" (%s %d))\n"
+    printf("(define-alien-type " #lispname " (%s %d))\n"

[ from the diff to grovel-headers.c, edited for clarity ]

With gcc-2.95.2 on x86 Linux, I'm getting
(define-alien-type "time-t" (sb!alien:signed 32))
rather than what we had before:
(define-alien-type time-t (sb!alien:signed 32))
and this difference causes the build to fail later.

I'm not sure what the correct solution to this is, I'm afraid, but I
thought I should give you feedback on the patch before I disappear
for a week.

This is the only issue I've seen; though I haven't gone through an
entire build yet make-target-1 was a lot less whingey :-)

Cheers,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

On Tue, 2002-03-26 at 14:32, Christophe Rhodes wrote:
> Thanks for this -- most of it is great, but there's a small problem that
> I'm seeing:
> 
> -    printf("(define-alien-type "##lispname##" (%s %d))\n"
> +    printf("(define-alien-type " #lispname " (%s %d))\n"
> 
> [ from the diff to grovel-headers.c, edited for clarity ]
> 
> With gcc-2.95.2 on x86 Linux, I'm getting
> (define-alien-type "time-t" (sb!alien:signed 32))
> rather than what we had before:
> (define-alien-type time-t (sb!alien:signed 32))
> and this difference causes the build to fail later.

This shouldn't be too hard to fix:

-    printf("(define-alien-type "##lispname##" (%s %d))\n"
+    printf("(define-alien-type \"" #lispname "\" (%s %d))\n"

Notice the escaped quotations in the addition.

I wonder if that's what was making my sbcl-solaris-hosted build fail. 
Must go fix!  Thanks for pointing this out.
-- 
Nathan  |  http://www.rose-hulman.edu/~froydnj/  |  Credo ut intelligam

      From Man's effeminate slackness it begins.  --Paradise Lost

On Tue, 2002-03-26 at 15:54, Nathan Froyd wrote:
> On Tue, 2002-03-26 at 14:32, Christophe Rhodes wrote:
> > With gcc-2.95.2 on x86 Linux, I'm getting
> > (define-alien-type "time-t" (sb!alien:signed 32))
> > rather than what we had before:
> > (define-alien-type time-t (sb!alien:signed 32))
> > and this difference causes the build to fail later.
> 
> This shouldn't be too hard to fix:
> 
> -    printf("(define-alien-type "##lispname##" (%s %d))\n"
> +    printf("(define-alien-type \"" #lispname "\" (%s %d))\n"

Actually, (covers face), this doesn't work.  But the original solution
did work, at least with both gcc 2.95.4 on Linux and gcc 3.0 on
Solaris.  So I'm not sure what's going on.

Have you actually built sbcl on solaris with sbcl on solaris?  I know
Rahul had problems with CMUCL 18c; my sbcl-on-solaris-as-xc build fails
in src/code/unix.lisp claiming that it doesn't know how big `struct
rusage' is and some other obscure stuff (will post more later).
-- 
Nathan  |  http://www.rose-hulman.edu/~froydnj/  |  Credo ut intelligam

      From Man's effeminate slackness it begins.  --Paradise Lost

On Tue, Mar 26, 2002 at 03:54:52PM -0500, Nathan Froyd wrote:
> On Tue, 2002-03-26 at 14:32, Christophe Rhodes wrote:
> > Thanks for this -- most of it is great, but there's a small problem that
> > I'm seeing:
> > 
> > -    printf("(define-alien-type "##lispname##" (%s %d))\n"
> > +    printf("(define-alien-type " #lispname " (%s %d))\n"
> > 
> > [ from the diff to grovel-headers.c, edited for clarity ]
> > 
> > With gcc-2.95.2 on x86 Linux, I'm getting
> > (define-alien-type "time-t" (sb!alien:signed 32))
> > rather than what we had before:
> > (define-alien-type time-t (sb!alien:signed 32))
> > and this difference causes the build to fail later.
> 
> This shouldn't be too hard to fix:
> 
> -    printf("(define-alien-type "##lispname##" (%s %d))\n"
> +    printf("(define-alien-type \"" #lispname "\" (%s %d))\n"
> 
> Notice the escaped quotations in the addition.

No, I think this is the wrong way round (though I could be wrong -- I'm
currently a long way from my C compiler -- sorry if I'm unclear :-)

What grovel-headers as of 0.7.2 gives us is
(define-alien-type time-t ...)
which is fine, as the symbol SB!UNIX:TIME-T is used in
src/code/unix.lisp. For me (and I don't know if this is compliant
behaviour from gcc-2.95.3 or not), your patch causes
stuff-groveled-from-headers to have lines of the form
(define-alien-type "time-t" ...)
which doesn't interact well with the rest of the sbcl code.

Possibly the simplest solution would be
+ printf("(define-alien-type %s (%s %d))\n", lispname, ...);
? Would that work for everyone?

Cheers,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

On Tue, 2002-03-26 at 17:07, Christophe Rhodes wrote:
> No, I think this is the wrong way round (though I could be wrong -- I'm
> currently a long way from my C compiler -- sorry if I'm unclear :-)
...
> Possibly the simplest solution would be
> + printf("(define-alien-type %s (%s %d))\n", lispname, ...);
> ? Would that work for everyone?

Ok, yeah, I see what you're saying.  Sorry, not thinking straight.

We could abuse the C preprocessor and just remove the quotes from the
first argument to DEFTYPE in grovel-headers.c... :)  But for the
straightfoward solution, yours probably works OK.  Then again, I'm not a
maintainer (for good reasons, as seen today!). :)
-- 
Nathan  |  http://www.rose-hulman.edu/~froydnj/  |  Credo ut intelligam

      From Man's effeminate slackness it begins.  --Paradise Lost

> On Tue, 2002-03-26 at 17:07, Christophe Rhodes wrote:
> > No, I think this is the wrong way round (though I could be wrong -- I'm
> > currently a long way from my C compiler -- sorry if I'm unclear :-)
> ...
> > Possibly the simplest solution would be
> > + printf("(define-alien-type %s (%s %d))\n", lispname, ...);
> > ? Would that work for everyone?
> 
> Ok, yeah, I see what you're saying.  Sorry, not thinking straight.
> 
> We could abuse the C preprocessor and just remove the quotes from the
> first argument to DEFTYPE in grovel-headers.c... :)  But for the
> straightfoward solution, yours probably works OK.  Then again, I'm not a
> maintainer (for good reasons, as seen today!). :)

Um, am I missing something bloody obvious?

cvs server: Diffing .
Index: grovel_headers.c
===================================================================
RCS file: /cvsroot/sbcl/sbcl/tools-for-build/grovel_headers.c,v
retrieving revision 1.6
diff -r1.6 grovel_headers.c
29c29
<     printf("(define-alien-type "##lispname##" (%s %d))\n", (((foo=-1)<0) ? "sb!alien:signed" : "unsigned"), (8 * (sizeof foo))); }
---
>     printf("(define-alien-type " lispname " (%s %d))\n", (((foo=-1)<0) ? "sb!alien:signed" : "unsigned"), (8 * (sizeof foo))); }

Resulting output:

;;;; This is an automatically generated file, please do not hand-edit it.
;;;; See the program "grovel_headers.c".

(in-package "SB!UNIX")

;;; types, types, types
(define-alien-type clock-t (sb!alien:signed 32))
(define-alien-type dev-t (unsigned 64))
(define-alien-type gid-t (unsigned 32))
(define-alien-type ino-t (unsigned 32))
(define-alien-type mode-t (unsigned 32))
(define-alien-type nlink-t (unsigned 32))
(define-alien-type off-t (sb!alien:signed 32))
(define-alien-type size-t (unsigned 32))
(define-alien-type time-t (sb!alien:signed 32))
(define-alien-type uid-t (unsigned 32))
...

Though, it seemingly worked to buidl SBCL as-was and I have *not* tried after.

//Ingvar

On Tue, Mar 26, 2002 at 04:48:01PM -0500, Nathan Froyd wrote:
> On Tue, 2002-03-26 at 15:54, Nathan Froyd wrote:
> > On Tue, 2002-03-26 at 14:32, Christophe Rhodes wrote:
> > > With gcc-2.95.2 on x86 Linux, I'm getting
> > > (define-alien-type "time-t" (sb!alien:signed 32))
> > > rather than what we had before:
> > > (define-alien-type time-t (sb!alien:signed 32))
> > > and this difference causes the build to fail later.
> > 
> > This shouldn't be too hard to fix:
> > 
> > -    printf("(define-alien-type "##lispname##" (%s %d))\n"
> > +    printf("(define-alien-type \"" #lispname "\" (%s %d))\n"
> 
> Actually, (covers face), this doesn't work.  But the original solution
> did work, at least with both gcc 2.95.4 on Linux and gcc 3.0 on
> Solaris.  So I'm not sure what's going on.

I'll look at it more deeply when I'm back, if it hasn't been solved
already :-)... in the meantime it's possible to kludge round it by
hand-editing output/stuff-groveled-from-headers.lisp to be as it is
wanted...

> Have you actually built sbcl on solaris with sbcl on solaris?  I know
> Rahul had problems with CMUCL 18c; my sbcl-on-solaris-as-xc build fails
> in src/code/unix.lisp claiming that it doesn't know how big `struct
> rusage' is and some other obscure stuff (will post more later).

I don't know about your error, but Rahul's is workaroundable if not
trivially fixable. Yes, I've built sbcl/solaris with itself -- it seemed
to "just work".

Disclaimer: I haven't actually run CMUCL on Solaris, but I think I know
what's caused the problem. At a guess, CMUCL/Solaris has underflow traps
enabled. So when the sbcl cross-compiler wants to create a denormalized
float, it causes a trap (see the definition of double-from-bits and the
code and comments at the end of src/code/cross-float.lisp).

The workaround is to disable underflow traps in the host compiler for
make-host-2; for CMUCL, I believe that the incantation is
(set-floating-point-modes :traps '(:overflow :invalid :divide-by-zero))

Sorry that this isn't as streamlined as we'd like it to be -- it wasn't
meant to be this hard :-/

Cheers,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

On Tue, Mar 26, 2002 at 10:32:27PM +0000, Ingvar wrote:
> > On Tue, 2002-03-26 at 17:07, Christophe Rhodes wrote:
> > > No, I think this is the wrong way round (though I could be wrong -- I'm
> > > currently a long way from my C compiler -- sorry if I'm unclear :-)
> > ...
> > > Possibly the simplest solution would be
> > > + printf("(define-alien-type %s (%s %d))\n", lispname, ...);
> > > ? Would that work for everyone?
> > 
> > Ok, yeah, I see what you're saying.  Sorry, not thinking straight.
> > 
> > We could abuse the C preprocessor and just remove the quotes from the
> > first argument to DEFTYPE in grovel-headers.c... :)  But for the
> > straightfoward solution, yours probably works OK.  Then again, I'm not a
> > maintainer (for good reasons, as seen today!). :)
> 
> Um, am I missing something bloody obvious?

[ snip bloody obvious solution ]

No, I don't think you are.

I'm back from my holidays now, and one of the things I will do for 0.7.2
is clean up the Solaris and gcc3 support -- I promise :-)

Cheers,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

On Tue, Mar 26, 2002 at 08:46:42AM -0500, Nathan Froyd wrote:
> Attached is a patch that will eliminate various warnings about
> implicitly defined functions in the runtime.  It also changes various
> multi-line string constants (which are deprecated in gcc 3.x) to be
> ANSI-compliant and includes a small ANSIfication in grovel-headers.c.

Thank you; I have merged this (with Ingvar's modification to the
grovel_headers.c change) into sbcl-0.7.2.6.

Work on the runtime is far from over; not counting the warnings from
pointer<->integer games, an x86/linux build gives 6 warnings and a
sparc/solaris build 13... most of these are probably trivially fixable
-- I haven't started looking into them yet.

Slightly worryingly, I have been unable to compile a solaris core from
the solaris binaries produced from cross-compiling from x86; I'm
slightly inclined to blame the hardware I'm working with (in that errors
occur in different places) and I don't believe that any of the changes
in the merged patch could have made the situation worse; nevertheless, I
would welcome independent confirmation or denial.

Known issues with the solaris port as of now: apart from Rahul Jain's
observation that cross-compilation from solaris/cmucl fails because of
underflow, it is hard to convince the runtime to build if your gcc is
configured to use /usr/ccs/bin/as rather than the GNU assembler, as the
.S files use GNU-specific syntax.  Aside from that, a probable cause of
lossage would be that the instruction cache is not being flushed, as I
overlooked it when doing the SPARC/Linux port; the code may need to be
copied over from CMUCL.

All feedback welcome,

Cheers,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

On Thu, 2002-04-04 at 11:54, Christophe Rhodes wrote:
> Thank you; I have merged this (with Ingvar's modification to the
> grovel_headers.c change) into sbcl-0.7.2.6.

Excellent.

> Work on the runtime is far from over; not counting the warnings from
> pointer<->integer games, an x86/linux build gives 6 warnings and a
> sparc/solaris build 13... most of these are probably trivially fixable
> -- I haven't started looking into them yet.

Are there only 13 on sparc/solaris?  I thought there were more than that
when I watched the build go...

> Slightly worryingly, I have been unable to compile a solaris core from
> the solaris binaries produced from cross-compiling from x86; I'm
> slightly inclined to blame the hardware I'm working with (in that errors
> occur in different places) and I don't believe that any of the changes
> in the merged patch could have made the situation worse; nevertheless, I
> would welcome independent confirmation or denial.

I just compiled 0.7.2.6 from solaris binaries; the host was compiled
from an x86 0.7.2.4 build.  This was on Solaris 2.8 (I can try 2.6) with
gcc 3.0.

Do you mean "can't compile solaris core" in the sense that the build
doesn't work or that the tests don't pass?  The core I just made doesn't
past tests (I think it horks on irrat.pure.lisp, but it appears to be
fine otherwise.
-- 
Nathan  |  http://www.rose-hulman.edu/~froydnj/  |  Credo ut intelligam

      From Man's effeminate slackness it begins.  --Paradise Lost

On Thu, Apr 04, 2002 at 06:56:07PM -0500, Nathan Froyd wrote:
> On Thu, 2002-04-04 at 11:54, Christophe Rhodes wrote:
> > Work on the runtime is far from over; not counting the warnings from
> > pointer<->integer games, an x86/linux build gives 6 warnings and a
> > sparc/solaris build 13... most of these are probably trivially fixable
> > -- I haven't started looking into them yet.
> 
> Are there only 13 on sparc/solaris?  I thought there were more than that
> when I watched the build go...

Oh, there are plenty more here; most of them, though, are known
"harmless" integer and pointer confusion (making pointer from integer
without cast, comparing two pointers of incompatible types, etc, etc,
etc); they should be fixed, of course, but they're a class of warning of
themselves, as the rest are not.

> > Slightly worryingly, I have been unable to compile a solaris core from
> > the solaris binaries produced from cross-compiling from x86; I'm
> > slightly inclined to blame the hardware I'm working with (in that errors
> > occur in different places) and I don't believe that any of the changes
> > in the merged patch could have made the situation worse; nevertheless, I
> > would welcome independent confirmation or denial.
> 
> I just compiled 0.7.2.6 from solaris binaries; the host was compiled
> from an x86 0.7.2.4 build.  This was on Solaris 2.8 (I can try 2.6) with
> gcc 3.0.

Oh, good.

> Do you mean "can't compile solaris core" in the sense that the build
> doesn't work or that the tests don't pass?  The core I just made doesn't
> past tests (I think it horks on irrat.pure.lisp, but it appears to be
> fine otherwise.

In the sense that the build doesn't work, but not in any repeatable
manner -- I'm more inclined to blame the hardware, since I'm causing my 
machine to thrash quite significantly.

As to irrat.pure.lisp: I'm not convinced of the utility of the tests in
there for the most part, actually; there are problems with the tests in
that they assume the weirdo 80-bit x86 precision. They do seem to have
caught some interestingness: pi can differ in the last significant digit
between architectures (and I don't know why -- it may depend on whether
the core was cross-compiled from a different architecture or not), but I
would have thought that tests for equality ± epsilon might be more
useful than exact string comparison.

Certainly I get tired that at every time having a heartstop, thinking 
"what have I broken now?", before realizing that the tests failed in
irrat.pure.lisp, and deleting it again :-) This will probably motivate
me to do something about it...

Cheers,

Christophe
-- 
Jesus College, Cambridge, CB5 8BL                           +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/                  (defun pling-dollar 
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)