Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Libm core dump with SIGILL

On 2015-08-21 15:17, Paul Koning wrote:

On Aug 21, 2015, at 8:35 AM, Greg Stark <stark%mit.edu@localhost> wrote:

While running the Postgres regression tests I found that the exp()
function in libm gets a SIGILL with certain arguments.

simh$  gcc -Wall  exp.c -lm
simh$ ./a.out
[4]   Illegal instruction (core dumped) ./a.out

On a modern architecture with IEEE floats:

$ gcc -Wall  exp.c -lm
$ ./a.out
exp(88.0297) = 1.70141e+38

I know the VAX floating points are not exactly IEEE and they may not
be able to represent this value but I would expect them to get a FPE
or signal overflow in some other way, not get a SIGILL?

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.

VAX float comes in 4 flavors: the original two, called "F" and "D" (32 and 64 bits) which were taken from the PDP-11 and predate IEEE -- and the newer two, called "G" and "H".  G is IEEE double precision (64 bits); H is 128 bit.  GCC can generate G-float code if you ask it but it looks like it does the older form by default.

Uh. No... While F and D comes from the PDP-11, G and H are just extensions of these, and none are IEEE compatible, and they all predate IEEE.

F/D float have an 8 bit exponent, which makes the upper limit just about the value you expected (1.7e+38).  So it looks like you just barely hit a float overflow.  And for F/G, the result of overflow is an overflow trap -- an exception.

Assuming the code/compiler do things right... :-)


Home | Main Index | Thread Index | Old Index