guile 1.8 and x86_64

guile 1.8 and x86_64

[Quanah Gibson-Mount]

guile 1.8 fails to compile for me on my x86_64 box.  I saw some previous 
thread about guile 1.7.xx having this issue, and I was wondering if there's 
been a fix since the 1.8 release.

guile reports:

Making all in libguile
make[2]: Entering directory 
`/afs/ir.stanford.edu/src/pubsw/languages/guile-1.8.0/build/@sys/libguile'
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc 
continuations.doc debug.doc deprecation.doc deprecated.doc discouraged.doc 
dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc evalext.doc 
extensions.doc feature.doc fluids.doc fports.doc futures.doc gc.doc 
goops.doc gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc gc-card.doc 
guardians.doc hash.doc hashtab.doc hooks.doc i18n.doc init.doc ioext.doc 
keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc 
numbers.doc objects.doc objprop.doc options.doc pairs.doc ports.doc 
print.doc procprop.doc procs.doc properties.doc random.doc rdelim.doc 
read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc smob.doc 
sort.doc srcprop.doc stackchk.doc stacks.doc stime.doc strings.doc 
srfi-4.doc srfi-13.doc srfi-14.doc strorder.doc strports.doc struct.doc 
symbols.doc threads.doc throw.doc values.doc variable.doc vectors.doc 
version.doc vports.doc weaks.doc ramap.doc unif.doc dynl.doc filesys.doc 
posix.doc net_db.doc socket.doc regex-posix.doc | 
GUILE="/afs/ir/src/pubsw/languages/guile-1.8.0/build/@sys/pre-inst-guile" 
../../../scripts/snarf-check-and-output-texi --manual > guile.texi || { rm 
guile.texi; false; }
ERROR: In procedure memoization:
ERROR: Bad binding (vector-set! x (unquote (caddr e)) y) in expression 
(letrec ((genmatch (lambda (x clauses match-expr) (let* ((length>= #) 
#<freed cell 0x2aaaabb57380; GC missed a reference> (blist #) (plist #) 
(code #)) (unreachable plist match-expr) (inline-let (quasiquote #))))) 
(genletrec (lambda (pat exp body match-expr) (let* ((length>= #) (eb-errf 
#) (x #) (p #) (bv #) (bindings #) (code #) (plist #) (x #) (m #) ...) 
(unreachable plist match-expr) (quasiquote (letrec # #))))) (gendefine 
(lambda (pat exp match-expr) (let* ((length>= #) (eb-errf #) (x #) (p #) 
(bv #) (bindings #) (code #) (plist #) (x #) (m #) ...) (unreachable plist 
match-expr) (quasiquote (begin # #))))) (pattern-var? (lambda (x) (and 
(symbol? x) (not (dot-dot-k? x)) (not (memq x #))))) (dot-dot-k? (lambda 
(s) (and (symbol? s) (if (memq s #) 0 (let* # #))))) (error-maker (lambda 
(match-expr) (cond ((eq? match:error-control #) (cons # #)) ((memq 
match:error-control #) (cons # #)) ((eq? match:error-control #) (let # #)) 
(else (match:syntax-err # "invalid value for match:error-control, legal 
values are"))))) (unreachable (lambda (plist match-expr) (for-each (lambda 
(x) (if # #)) plist))) (validate-pattern (lambda (pattern) (letrec 
((simple? #) (ordinary #) (quasi #) (ordlist #)) (ordinary pattern)))) 
(unquote e) (inline-let (lambda (let-exp) (letrec ((occ #) (subst #) 
(const? #) (isval? #) (small? #)) (let loop (# # #) (cond # # #))))) ...) 
(list genmatch genletrec gendefine pattern-var?)).
make[2]: *** [guile.texi] Error 1
make[2]: Leaving directory 
`/afs/ir.stanford.edu/src/pubsw/languages/guile-1.8.0/build/@sys/libguile'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/afs/ir.stanford.edu/src/pubsw/languages/guile-1.8.0/build/@sys'
make: *** [all] Error 2


Thanks,
Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Ludovic Courtès]

Hi,

Quanah Gibson-Mount <quanah@stanford.edu> writes:

> guile 1.8 fails to compile for me on my x86_64 box.  I saw some
> previous thread about guile 1.7.xx having this issue, and I was
> wondering if there's been a fix since the 1.8 release.

It's a known problem with 1.8.0 that is being worked on [0].  Still, if
you would like to help, I think you'd be welcomed.  ;-)

Thanks,
Ludovic.

[0] http://lists.gnu.org/archive/html/guile-devel/2006-03/msg00057.html


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Neil Jerram]

ludovic.courtes@laas.fr (Ludovic Courtès) writes:

> Hi,
>
> Quanah Gibson-Mount <quanah@stanford.edu> writes:
>
>> guile 1.8 fails to compile for me on my x86_64 box.  I saw some
>> previous thread about guile 1.7.xx having this issue, and I was
>> wondering if there's been a fix since the 1.8 release.
>
> It's a known problem with 1.8.0 that is being worked on [0].  Still, if
> you would like to help, I think you'd be welcomed.  ;-)

Can you tell us what version of gcc you are compiling with, and
whether you are specifying any extra compilation flags to ./configure?

Thanks,
    Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Quanah Gibson-Mount]

--On Monday, April 10, 2006 11:55 PM +0100 Neil Jerram 
<neil@ossau.uklinux.net> wrote:

> ludovic.courtes@laas.fr (Ludovic Courtès) writes:
>
>> Hi,
>>
>> Quanah Gibson-Mount <quanah@stanford.edu> writes:
>>
>>> guile 1.8 fails to compile for me on my x86_64 box.  I saw some
>>> previous thread about guile 1.7.xx having this issue, and I was
>>> wondering if there's been a fix since the 1.8 release.
>>
>> It's a known problem with 1.8.0 that is being worked on [0].  Still, if
>> you would like to help, I think you'd be welcomed.  ;-)
>
> Can you tell us what version of gcc you are compiling with, and
> whether you are specifying any extra compilation flags to ./configure?

amd64-linux26:/afs/ir/src/pubsw/languages/guile-1.6.7> /usr/pubsw/bin/gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc-4.0.2/configure --datadir=/lib --libexecdir=/lib 
--sharedstatedir=/lib --prefix=/usr/pubsw --enable-threads --with-gnu-as 
--with-as=/usr/pubsw/bin/as --with-gnu-ld --with-ld=/usr/pubsw/bin/ld 
--with-libintl-prefix=/usr/pubsw --with-libiconv-prefix=/usr/pubsw 
--disable-multilib --enable-libada --enable-languages=c,c++,f95,objc,ada
Thread model: posix
gcc version 4.0.2



amd64-linux26:/afs/ir/src/pubsw/languages/guile-1.6.7> wrap configure
mkdir -p build/amd64_linux26
cd build/@sys && CC=/usr/pubsw/bin/gcc CXX=/usr/pubsw/bin/g++ CFLAGS=-O2 
CXXFLAGS=-O2 sh ../../configure --datadir='${prefix}/lib' 
--libexecdir='${prefix}/lib' --sharedstatedir='${prefix}/lib' 
--prefix=/usr/pubsw --with-libiconv-prefix=/usr/pubsw 
--with-libintl-prefix=/usr/pubsw

is my configure line.

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Neil Jerram]

Quanah Gibson-Mount <quanah@stanford.edu> writes:

> amd64-linux26:/afs/ir/src/pubsw/languages/guile-1.6.7> /usr/pubsw/bin/gcc -v
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ../../gcc-4.0.2/configure --datadir=/lib
> --libexecdir=/lib --sharedstatedir=/lib --prefix=/usr/pubsw
> --enable-threads --with-gnu-as --with-as=/usr/pubsw/bin/as
> --with-gnu-ld --with-ld=/usr/pubsw/bin/ld
> --with-libintl-prefix=/usr/pubsw --with-libiconv-prefix=/usr/pubsw
> --disable-multilib --enable-libada
> --enable-languages=c,c++,f95,objc,ada
> Thread model: posix
> gcc version 4.0.2

[...]

Many thanks; we are working on this and hope to have a fix soonish.
If you are keen to have Guile 1.8 working on this box, we believe a
successful workaround is to compile with an older GCC.  3.3.5 seems
OK, for example.

Regards,
     Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Quanah Gibson-Mount]

--On Tuesday, April 11, 2006 9:37 PM +0100 Neil Jerram 
<neil@ossau.uklinux.net> wrote:

> Quanah Gibson-Mount <quanah@stanford.edu> writes:
>
>> amd64-linux26:/afs/ir/src/pubsw/languages/guile-1.6.7>
>> /usr/pubsw/bin/gcc -v Using built-in specs.
>> Target: x86_64-unknown-linux-gnu
>> Configured with: ../../gcc-4.0.2/configure --datadir=/lib
>> --libexecdir=/lib --sharedstatedir=/lib --prefix=/usr/pubsw
>> --enable-threads --with-gnu-as --with-as=/usr/pubsw/bin/as
>> --with-gnu-ld --with-ld=/usr/pubsw/bin/ld
>> --with-libintl-prefix=/usr/pubsw --with-libiconv-prefix=/usr/pubsw
>> --disable-multilib --enable-libada
>> --enable-languages=c,c++,f95,objc,ada
>> Thread model: posix
>> gcc version 4.0.2
>
> [...]
>
> Many thanks; we are working on this and hope to have a fix soonish.
> If you are keen to have Guile 1.8 working on this box, we believe a
> successful workaround is to compile with an older GCC.  3.3.5 seems
> OK, for example.

Well, I'm required to use 4.0.2 at this point, so I'll just wait until 1.8 
works.   1.6.7 is a major upgrade over the 1.3.4 we had previously, so I 
went with that. ;)

--Quanah


--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Miroslav Lichvar]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

Hi,

attached is a patch that seems to fix the problem with gcc4 and 64bit
architectures.

The scm_mark_locations function in gc-mark.c calls scm_gc_mark on
everything located in one of the allocated segments. Shouldn't there
be a check if the address is at least scm_t_cell aligned? 

Is it correct or is it just plain luck it works with the patch?

Thanks,

-- 
Miroslav Lichvar

[-- Attachment #2: gcmark.patch --]
[-- Type: text/plain, Size: 407 bytes --]

--- libguile/gc-mark.c.orig	2006-02-12 14:29:12.000000000 +0100
+++ libguile/gc-mark.c	2006-05-05 14:41:07.000000000 +0200
@@ -433,6 +433,8 @@
   for (m = 0; m < n; ++m)
     {
       SCM obj = * (SCM *) &x[m];
+      if ((scm_t_bits)obj & (sizeof (scm_t_cell) - 1))
+        continue;
       long int segment = scm_i_find_heap_segment_containing_object (obj);
       if (segment >= 0)
 	scm_gc_mark (obj);

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Miroslav Lichvar]

On Fri, May 05, 2006 at 04:05:34PM +0200, Miroslav Lichvar wrote:
> The scm_mark_locations function in gc-mark.c calls scm_gc_mark on
> everything located in one of the allocated segments. Shouldn't there
> be a check if the address is at least scm_t_cell aligned? 

Looks like the CELL_P macro is there exactly for this purpose, the
following change in private-gc.h is probably the right thing to do.

137c137
< #define CELL_P(x)  (SCM_ITAG3 (x) == scm_tc3_cons)
---
> #define CELL_P(x)  (!(SCM_UNPACK (x) & (sizeof (scm_t_cell) - 1)))

-- 
Miroslav Lichvar


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Marius Vollmer]

Miroslav Lichvar <mlichvar@redhat.com> writes:

> On Fri, May 05, 2006 at 04:05:34PM +0200, Miroslav Lichvar wrote:
> > The scm_mark_locations function in gc-mark.c calls scm_gc_mark on
> > everything located in one of the allocated segments. Shouldn't there
> > be a check if the address is at least scm_t_cell aligned? 

Yes!  I haven't really seen the 64bit problem myself, but you theory
sounds very convincing.  This is very likely the solution.
 
What about this this patch, tho, which is exactly the same as yours,
but a bit more similar to the code we have:

137c137
< #define CELL_P(x)  (SCM_ITAG3 (x) == scm_tc3_cons)
---
> #define CELL_P(x)  ((SCM_UNPACK(x) & (sizeof(scm_t_cell)-1)) == scm_tc3_cons)

I'll put it in right away, with a comment.

Thanks a 18446744073709551616!

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Andy Wingo]

Hi,

On Mon, 2006-05-08 at 00:29 +0300, Marius Vollmer wrote:
> 137c137
> < #define CELL_P(x)  (SCM_ITAG3 (x) == scm_tc3_cons)
> ---
> > #define CELL_P(x)  ((SCM_UNPACK(x) & (sizeof(scm_t_cell)-1)) == scm_tc3_cons)

I don't really understand how the region can give you unaligned
pointers, but I do confirm that this patch allows me to build guile.
Rock!

Running make check stops with compilation errors of the form:

test-conversion.c:32: warning: format ‘%Ld’ expects type ‘long long
int’, but argument 4 has type ‘scm_t_intmax’

There are about 20 of these: http://paste.lisp.org/display/19791

I don't have time to look at this atm, just wanted to give the quick
positive feedback :-)

Cheers,
-- 
Andy Wingo
http://wingolog.org/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Marius Vollmer]

Andy Wingo <wingo@pobox.com> writes:

> Hi,
> 
> On Mon, 2006-05-08 at 00:29 +0300, Marius Vollmer wrote:
> > 137c137
> > < #define CELL_P(x)  (SCM_ITAG3 (x) == scm_tc3_cons)
> > ---
> > > #define CELL_P(x)  ((SCM_UNPACK(x) & (sizeof(scm_t_cell)-1)) == scm_tc3_cons)
> 
> I don't really understand how the region can give you unaligned
> pointers, but I do confirm that this patch allows me to build guile.

Excellent!

Here is what is going on: the CELL_P predicate is used during the
conservative scanning of the GC to decide whether a random word can
possibly be a non-immediate SCM value.  Non-immediate values are the
ones that point into the heap.  The type tag for such a non-immediate
value is "lower three bits zero".  On 32-bit architectures, a cell is
8 bytes, which means that a non-immediate value is always aligned to a
cell.  On 64-bit machines, a cell is 16 bytes, and that means that a
word with "lower three bits zero" can still be invalid because it
points into the middle of a cell.

(We have similar check already for double-cells, which are 16 bytes on
32-bit machines.)

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Neil Jerram]

Marius Vollmer <mvo@zagadka.de> writes:

> Here is what is going on: the CELL_P predicate is used during the
> conservative scanning of the GC to decide whether a random word can
> possibly be a non-immediate SCM value.  Non-immediate values are the
> ones that point into the heap.  The type tag for such a non-immediate
> value is "lower three bits zero".  On 32-bit architectures, a cell is
> 8 bytes, which means that a non-immediate value is always aligned to a
> cell.  On 64-bit machines, a cell is 16 bytes, and that means that a
> word with "lower three bits zero" can still be invalid because it
> points into the middle of a cell.
>
> (We have similar check already for double-cells, which are 16 bytes on
> 32-bit machines.)

That's great, but I believe there's one detail still to be explained:
why is it a problem with GCC 4 but not with GCC 3?

    Neil



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: guile 1.8 and x86_64

[Andy Wingo]

(Why am I not getting mails to the list? Is mailman being "smart", or
the mailing lists slow? Anyway, replying to all..)

On Tue, 2006-05-09 at 07:49 +0100, Neil Jerram wrote:
> Marius Vollmer <mvo@zagadka.de> writes:
> > On 64-bit machines, a cell is 16 bytes, and that means that a
> > word with "lower three bits zero" can still be invalid because it
> > points into the middle of a cell.

Sounds plausible :)

> That's great, but I believe there's one detail still to be explained:
> why is it a problem with GCC 4 but not with GCC 3?

I experienced problems with gcc3 as well, 3.3 at least, under some
circumstances. I suspect this very much depends on what values the
compiler decides to put on the stack, which depends on your CFLAGS.

Speaking of which, a -g compile on PPC uses quite a lot of stack -- I
had to up the default limit in order to get anything to work (for
example, compiling psyntax). That would be another issue though...

Regards,
-- 
Andy Wingo
http://wingolog.org/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Default stack limit

[Marius Vollmer]

Andy Wingo <wingo@pobox.com> writes:

> Speaking of which, a -g compile on PPC uses quite a lot of stack -- I
> had to up the default limit in order to get anything to work (for
> example, compiling psyntax). That would be another issue though...

Yeah, it's a "known issue" also on x86.  The default stack limit is a
bit tight for a "-O0" build.  I guess we should just double it or
something.  Or should we make the default 'unlimited'?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Default stack limit

[Andy Wingo]

Hi,

On Wed, 2006-05-10 at 01:31 +0300, Marius Vollmer wrote:
> Andy Wingo <wingo@pobox.com> writes:
> 
> > Speaking of which, a -g compile on PPC uses quite a lot of stack -- I
> > had to up the default limit in order to get anything to work (for
> > example, compiling psyntax). That would be another issue though...
> 
> Yeah, it's a "known issue" also on x86.  The default stack limit is a
> bit tight for a "-O0" build.  I guess we should just double it or
> something.  Or should we make the default 'unlimited'?

I think that 50000 words (200KB/400KB) should be more than enough for
anyone.

Haha. (Right now it is 20000 words.) Seriously, we should look into why
this is the case, has SCM had similar issues with newer GCC, etc. Is it
just the compilers that changed, or was it frames, or ...

Regards,
-- 
Andy Wingo
http://wingolog.org/



_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: Default stack limit

[Kevin Ryde]

Andy Wingo <wingo@pobox.com> writes:
>
> Is it just the compilers that changed,

Seems to be, it's still fine with for instance gcc 2.95 unoptimized.

gcc 4 seems to use up a lot more stack in CEVAL()/DEVAL() when
unoptimized, something like 900 bytes for me, but why that's so I
couldn't tell.  (Keeping stack usage in that func to a minimum would
probably be a good thing in general though, as the main recursion when
interpreting ...)


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel