Changes between Initial Version and Version 1 of Ticket #22191, comment 22

01/18/17 21:44:17 (3 years ago)


  • Ticket #22191, comment 22

    initial v1  
    11Replying to [comment:20 dimpase]:
    2 > > It seems that the sage action for SIGFPE is to coredump. That's what we're seeing.
    3 >
    4 > no, it is not.
     2> In fact, ECL 16.1.3 has a new command line switch, `-no-trap-fp`, and it works.
    6 Yes it is, and it is not in contradiction with what you observe. Sage's standard fenv is to NOT RAISE SIGFPE upon overflow. ECL changes the fenv to raise SIGFPE. Sage does not set a SIGFPE handler because we don't expect them to ever occur. Hence, we coredump if it does occur.
     4The corresponding ECL command is `(si::trap-fpe t nil)`, so we could just pass that to ECL just after cl_boot. That might be easier/more efficient than passing it in the argv.
    8 > Sage's action on FP overflow is to return infinity. Why does ECL continue to mess around with it, even if told not to? In fact, ECL 16.1.3 has a new command line switch, `-no-trap-fp`, and it works.
    10 Ah, so the problem is solved? Go with that then. It's just a matter of figuring out how to pass that option to cl_boot then.
    12 I have pushed a modification of your ecl16.1.3exp branch to include resetting of of the fenv. That seems to solve the problems too, but if we can just convince ECL to never set the fenv to raise SIGFPEs, that's probably a more efficient solution. Feel free to change back to your other branch. Pushing via "git-trac" was the only way I knew how to push the branch to trac at all.
    13 ----
    14 New commits:
    15 ||[ a2cadc0]||{{{experimenting with using ECLs SIGFPE}}}||
     6This should put ECL in agreement about what the fenv FPE raise flags are supposed to be (and then it also doesn't matter what SIGFPE handler ECL uses, because the signals will not occur, so we don't need to restore ECL's SIGFPE handler for ECL code either.