[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2
From: |
Ken Raeburn |
Subject: |
Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2 |
Date: |
Wed, 18 Nov 2009 15:40:21 -0500 |
On Nov 18, 2009, at 04:37, Ludovic Courtès wrote:
From time to time, I test it on some “exotic” hardware architectures
of
the GCC Compile Farm (MIPS, Alpha, PPC64, etc.), and it’s been working
pretty well so far. I also got accounts on Tru64, AIX, and now
Solaris
and HP-UX, which I’m hoping to put to good use by the time we
release 2.0.
Actually, I wouldn't consider any of those terribly "exotic", unless
you're using one of the early Alphas that didn't support byte-access
operations. But at least we get some tests with strict memory
alignment requirements, etc. Windows testing would be kind of
important, too. Have access to any embedded systems? (Of course, if
they're not POSIX, the thread system would require some more porting
work... and it might show up areas where we've made other unwarranted
assumptions.)
Actually, Alpha is also interesting in that the spec permits weak
memory ordering -- so that one processor could execute "x = 1; y = 2;"
and even without the compiler playing games, a second processor may
see y modified before x. Such a machine can easily support C
(multiprocessor interactions are outside the spec) and POSIX (mutex
calls can incorporate memory barriers to force synchronization), but I
believe libguile assumes strict ordering between threads. I don't
know if the actual processor implementations or OSes permit such
reordering. Testing Guile on a multiprocessor system using weak
memory ordering would be interesting; I suspect, though, that it would
simply not work reliably.
That said, I’m not too worried about the Cray pointer thing. IOW,
it’s
OK for me to live with potential Cray breakage until someone with
access
to such a machine (how many are there around the world?) can come up
with a bug report or a fix.
It would be "better" in some sense if someone could try it out and let
us know for sure what the situation is -- if any of the machines still
exist. I wouldn't try to fix it for the Cray without someone out
there actively interested in using that version, but I don't want to
turn a blind eye to problems I'm confident would come up for people
in reasonable (if unusual) C environments. And I'm concerned that the
fixes would involve things like changing a macro, that currently works
with SCM or pointer types, into two macros, one for SCM values and one
for pointers -- that would mean an API change might be required in
order to finish a port.
Now, if ‘SCM_DEBUG_TYPING_STRICTNESS’ can help us prevent breakage,
that’s nice. I’ve never used it so far, and never felt the need to
use
it, but I’d be glad to follow your lead on this matter. :-)
That's one... ;-)
Ken