[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... ;-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]