Re: more compilation failures: -DSCM_DEBUG_TYPING_STRICTNESS=2

[Ken Raeburn]

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