Re: Libm core dump with SIGILL

[Paul Koning <paulkoning%comcast.net@localhost>]

> On Aug 21, 2015, at 9:29 AM, Greg Stark <stark%mit.edu@localhost> wrote:
> 
> On Fri, Aug 21, 2015 at 2:24 PM, Johnny Billquist <bqt%update.uu.se@localhost> wrote:
>>> 
>>> SIGILL is a compiler bug (if the implementation of exp() is in C) or a
>>> programmer error (if it's in assembler).
>> 
>> 
>> We should check this. There is trickery going on with VAX FP, in order to
>> somewhat achieve some of the similar properties of IEEE FP. I know that have
>> bitten me in the past, and it might even be needed to check in gcc itself,
>> as the actual libraries might not even be invoked.
> 
> 
> Sorry, I should have included the versions of things
> 
> This is on a freshly installed NetBSD 6.1.5 on simh from a recently
> checked out git tree:
> 
> simh# uname -a
> NetBSD simh 6.1.5 NetBSD 6.1.5 (GENERIC) vax
> 
> simh# gcc --version
> gcc (GCC) 4.1.3 20080704 prerelease (NetBSD nb3 20111107)
> 
> $ ./vax -h
> MicroVAX 3900 simulator V4.0-0 Beta        git commit id: f3af74e4
> 
> The backtrace is actually a bit deeper than just exp()
> 
> #0  0x7f7b6984 in infnan (34) from /usr/lib/libm.so.0
> #1  0x7f7b6810 in scalb (16512, 1179648, 17406, 0) from /usr/lib/libm.so.0
> #2  0x7f7b66df in exp (255017904, 735823842) from /usr/lib/libm.so.0

Ok.  It's intentional, but I would call this a design error.  Look at libm/arch/vax/n_infnan.S, it ends in an explicit "reserved operand" error.  Why anyone would do that rather than generating the exception intended for this purpose (floating point error) is unclear.

	paul