> <ragge@ludd.luth.se> writes:
> 
> > This is correct behavoiur, NaN on vax is considered an
> > illegal value to deal with.  Actually there is no NaN on vax,
> > so it is setup to give a trap instead.
> 
> So, PostgreSQL should, where it parses a "NaN" string as data input,
> generate an error itself (illegal float, not implemented, whatever),
> to keep strtod() from crashing the database backup.  OK.
> 
> But what about that polyd thing?  The only change I've made to libm
> was to comment out that single instruction from the assembly source to
> atan2(), and, while atan2() now definitely doesn't work, code that
> uses it no longer crashes on an illegal instruction.  However, I'm
> afraid I'm out of my depth when it comes to finding out where in the
> emulation code it's at when it happens...
> 
> Can you suggest something I can do to test further?
> 
A quick thing to do is to change the '#undef EMULATE_INKERNEL' to
'#define EMULATE_INKERNEL' in the beginning of the file unimpl_emul.S,
and see if the kernel spits out something informative.

-- Ragge