Re: guile-1.8.5 test failures

[Neil Jerram]

2008/5/29 Peter O'Gorman <address@hidden>:
>
> We built guile-1.8.5 on multiple machines with the native compilers and
> these patches:
>
> http://lists.gnu.org/archive/html/guile-devel/2008-05/msg00020.html
> http://lists.gnu.org/archive/html/guile-devel/2008-05/msg00017.html
> (attached patch)

> For ia64-hpux the situation is not quite that good. With all three
> patches applied guile builds, but the tests go like this:
...
> ERROR: Stack overflow
> FAIL: test-num2integral
...
> ERROR: Stack overflow
> FAIL: test-asmobs
...
> ERROR: Stack overflow
> FAIL: test-conversion
> ERROR: Stack overflow
> ABORT: (stack-overflow)
...
> Running alist.test
> ERROR: Stack overflow
> FAIL: check-guile

> Without the stack size or ia64 patches applied, the results are similar
> to Tru64:
>
> PASS: test-system-cmds
> PASS: test-require-extension
> PASS: test-bad-identifiers
> PASS: test-num2integral
> PASS: test-round
> PASS: test-gh
> PASS: test-asmobs
> PASS: test-list

So on this platform (ia64-hpux), it looks like the stack calibration
patch causes the stack overflows.  I imagine that could happen if (1)
the calibration Scheme code in boot-9.scm consumed little or no stack
- perhaps because of the compiler having lots of registers available,
and/or doing tail call frame elimination (that probably isn't the
right term for it, but hopefully it's clear what I mean!) - and (2)
the real C/Scheme code that runs later uses on average much more stack
per frame.

In another thread, Ludovic measured a value of 0.07 for the calibrated
m value on ia64-unknown-linux-gnu:

> * ia64-unknown-linux-gnu (itanium2), GCC 4.1.2
>   ;; Stack calibration: (x1 x2 y1 y2 m c) = (170 690 10 50 0.0769230769230769 
> -3.07692307692308)

This means that calibration reduces the maximum allowed stack depth
from 20000 to 1400 words.

If you still have the build around, and could run ./pre-inst-guile -q
with it, that should output a ";; Stack calibration" line like the one
above, and would allow us to confirm (or deny) that the calibrated m
value was very low.

Regards,
       Neil