On Tue, Mar 5, 2024 at 6:05 AM Camm Maguire <c...@maguirefamily.org> wrote:
> Greetings! > > Richard Fateman <fate...@gmail.com> writes: > > > 2. fix sbcl flags so that the handler still works after the first > floating-point error.. > > Not sure about sbcl, but this sounds like the standard IEEE SIGFPE > handling in which it is impossible to continue or return from the > instruction raising the signal without disabling the trap. One can > lonjmp somewhere else leaving the trap in place. It is not clear if > this explains your results as it does not appear you are trying to > continue. See the following in GCL: > > > ============================================================================= > > >(fpe::break-on-floating-point-exceptions :floating-point-overflow t) > > (:FLOATING-POINT-OVERFLOW) > > >(expt 2.0 1000000) > > Correctable error: > Fast links are on: do (si::use-fast-links nil) for debugging > Signalled by EXPT. > If continued: Continue disabling floating point exception trapping > INTERNAL-SIMPLE-FLOATING-POINT-OVERFLOW: > Arithmetic error when performing (:INSN "mulsd 0x8(%rsp),%xmm0 ;" :OP > ...) on (1.3407807929942598E154 1.3407807929942598E154): > > Broken at EXPT. Type :H for Help. > 1 (continue) Continue disabling floating point exception trapping > 2 Return to top level. > >>1 > > #<inf> > Is this the current development version of gcl? What's the difference between continuing and aborting here? Does this mean that if I had done (* 10 (expt 2d0 100000)) and selected the continue restart, I would have gotten #<inf>? If I had selected option 2, would the traps be preserved? -- Ray
