Re: [Sbcl-help] FreeBSD installation fails sbcl-0.8.16/tests/float.pure.lisp

[Christophe R. <cs...@ca...>]

Hello "SBCL-Hackers",

SBCL-Hackers@Jovi.Net writes:

> The compiler hoses deliberately erroneous test code.  When constant
> folding blows up, it should punt optimization, compile as written
> and let the runtime code signal the desired error.  Suggestions?

Your transcript is testing the wrong thing, and SBCL already does what
you suggest.

> PS: Perhaps RAISES-ERROR? is at fault.

RAISES-ERROR? is not defined in the session that you've demonstrated
below.

> $ cd /usr/ports/lang/sbcl/work/sbcl-0.8.16/tests
> $ ../src/runtime/sbcl --core ../output/sbcl.core
> * (SCALE-FLOAT 1.0 MOST-POSITIVE-FIXNUM)
>
> debugger invoked on a FLOATING-POINT-OVERFLOW in thread 89693:
>   arithmetic error FLOATING-POINT-OVERFLOW signalled
> Operation was SCALE-FLOAT, operands (1.0 536870911).

This is correct.

> * (raises-error? (scale-float 1.0 most-positive-fixnum) floating-point-overflow)
> ; in: LAMBDA NIL
> ;     (SCALE-FLOAT 1.0 MOST-POSITIVE-FIXNUM)
> ; 
> ; caught STYLE-WARNING:
> ;   Lisp error during constant folding:
> ;   arithmetic error FLOATING-POINT-OVERFLOW signalled
> ;   Operation was SCALE-FLOAT, operands (1.0 536870911).
> ;     (RAISES-ERROR? (SCALE-FLOAT 1.0 MOST-POSITIVE-FIXNUM) FLOATING-POINT-OVERFLOW)
> ; --> LOCALLY PROGN 
> ; ==>
> ;   (RAISES-ERROR? (SCALE-FLOAT 1.0 MOST-POSITIVE-FIXNUM) FLOATING-POINT-OVERFLOW)
> ; 
> ; caught WARNING:
> ;   undefined variable: FLOATING-POINT-OVERFLOW
> ; 
> ; caught STYLE-WARNING:
> ;   undefined function: RAISES-ERROR?
>
> ; 
> ; caught WARNING:
> ;   This variable is undefined:
> ;     FLOATING-POINT-OVERFLOW
>
> ; 
> ; caught STYLE-WARNING:
> ;   This function is undefined:
> ;     RAISES-ERROR?
> ; 
> ; compilation unit finished
> ;   caught 2 WARNING conditions
> ;   caught 3 STYLE-WARNING conditions
>
> debugger invoked on a FLOATING-POINT-OVERFLOW in thread 89693:
>   arithmetic error FLOATING-POINT-OVERFLOW signalled
> Operation was SCALE-FLOAT, operands (1.0 536870911).

Absent a macro definition for RAISES-ERROR?, this is also correct.
The compiler caught the constant-folding error, left the call in as
is; the arguments to the RAISES-ERROR? function are evaluated from
left-to-right, so the first argument form signals the error at
runtime, as it should.

Since I suspect you (whoever you are) may have had a reason for
sharing with us this completely reasonable transcript of correct
behaviour, you may seeing something awry in SBCL's treatment of
floating point control word restoration from (kernel-level) signal
handlers.  What needs to happen when the sbcl process returns from a
kernel trap is for the floating point environment to be restored in as
much as that is possible to the state it was in before the trap was
taken; in some cases, it is reasonable for the kernel to frob the
control word (say, if we have just taken a trap) but in other cases
it's less reasonable; whether the kernel is reasonable or not, of
course, we have to deal with it.

So, if you're getting an error in a test file regarding floating point
overflow, things to look at would include your kernel's source for
information about what happens to the floating point control word when
a process returns from a kernel signal handler into user space.  The C
function os_restore_fp_control() and the segments of control word
manipulation in src/runtime/x86-assem.S, in the call_into_lisp and
call_into_c functions, should also be examined.

Cheers,

Christophe