From: Thiemo Seufer <ths@networkno.de>
To: Neil Jerram <neiljerram@googlemail.com>
Cc: 481378@bugs.debian.org, guile-devel <guile-devel@gnu.org>
Subject: Bug#481378: Guile-1.8 FTBFS on mips (and other architectures)
Date: Wed, 28 May 2008 15:45:29 +0100 [thread overview]
Message-ID: <20080528144529.GA4469@networkno.de> (raw)
In-Reply-To: <49dd78620805261046t55478b23l8d0d8a45582dd1af@mail.gmail.com>
Neil Jerram wrote:
> 2008/5/24 Thiemo Seufer <ths@networkno.de>:
>
> > 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
next prev parent reply other threads:[~2008-05-28 14:45 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080515163940.GA23926@networkno.de>
[not found] ` <49dd78620805241400s2edb4ab9p173831bc3f4ca82@mail.gmail.com>
[not found] ` <20080524214349.GA27042@networkno.de>
2008-05-26 17:46 ` Bug#481378: Guile-1.8 FTBFS on mips (and other architectures) Neil Jerram
2008-05-28 14:45 ` Thiemo Seufer [this message]
2008-05-28 22:02 ` Neil Jerram
2008-05-29 2:29 ` Thiemo Seufer
[not found] ` <49dd78620805310905q24647eft9e46f41b0619e8ee@mail.gmail.com>
2008-05-31 16:18 ` Fwd: " Neil Jerram
2008-07-12 18:51 ` Neil Jerram
2008-07-15 20:10 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080528144529.GA4469@networkno.de \
--to=ths@networkno.de \
--cc=481378@bugs.debian.org \
--cc=guile-devel@gnu.org \
--cc=neiljerram@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).