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... :-) Johnny