unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
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




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