Neil Jerram wrote:
> 2008/5/24 Thiemo Seufer <[EMAIL PROTECTED]>:
>
> > Neil Jerram wrote:
> > >
> > > I believe those definitions came from the Boehm GC library. Do you
> > happen
> > > to know whether similar improvements have already been applied to Boehm
> > GC?
> >
> > The development version of Boehm GC carries a subset of it since:
> >
> > http://bdwgc.cvs.sourceforge.net/bdwgc/bdwgc/include/private/gcconfig.h?r1=1.28&r2=1.29
> >
> > This might be enough to make it work, altough I believe my patch is
> > preferable.
>
>
> OK thanks; I will commit your patch upstream (Guile). Will you take care of
> pushing to Boehm GC, if you want to do that?
I'll send a patch upstream.
> > So is it the case that the stack actually grows down on mips (and mipsel
> > and
> > > powerpc)?
> >
> > Yes. (This is the the case for almost all machines nowdays.)
> >
> > > Did you see (or work out) exactly how gcc was outsmarting the
> > > test?
> >
> > No, I only concluded this from the test's incorrect result.
>
>
> My guess is that unsigned long is only 32-bit, and so truncation of a 64-bit
> pointer invalidates the comparison. Would that make sense?
>
> Google codesearch indicates that other projects use char and char * in this
> kind of detection code. Therefore, if you wouldn't mind trying it out, it
> would be interesting to see if the attached patch will also fix this. (I'm
> afraid I currently can't reproduce the seg fault on my own 64-bit test
> machines.)
After a closer look I believe the logic of the test is just plain wrong:
aux (l) unsigned long l;
{ int x; exit (l >= ((unsigned long)&x)); }
main () { int q; aux((unsigned long)&q); },
The test returns true for a downward-growing stack, but that sets
SCM_I_GSC_STACK_GROWS_UP=1 ! For paranoia reasons I checked that
the test behaves the same on mips, powerpc and i386.
Using "(l < ((unsigned long& ..." does the right thing. Amazingly
this means the test is wrong on all platforms, and guile appears to
mostly cope with it. :-)
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
