It seems to be a bug in the convenience packages (and WSeB according to the thread). FFmpeg worked perfectly on Warp V4 here, passing all the tests, run on eCS, it crashed with a sigfpu exception.
Bitwise added a fix/work around in libc066 IIRC so GCC programs no longer suffer from the fpu exceptions, so I was thinking that Firefox or any recent libc program would reset the FCW control word preventing the exception. As many programs are built with GCC and some are in various startup folders, the problem usually doesn't happen. Apparently christech isn't running any GCC programs when starting up EPMD.
Results from Michal's test case, libc vs emx.
H:\tmp>test_emx.exe
cw = 0x7F
cw = 0x7F
cw = 0x37F
cw = 0x37F
5.56268e-309
H:\tmp>test_libc.exe
cw = 0X7F
cw = 0X7F
cw = 0X7F
cw = 0X7F
5.56268e-309
Couldn't tell from the thread if the correct answer should be zero or 5.5628e-309, which is very small.
Doodle added this to Cairo,
static inline void
DisableFPUException (void)
{
unsigned short usCW;
/* Some OS/2 PM API calls modify the FPU Control Word,
* but forget to restore it.
*
* This can result in XCPT_FLOAT_INVALID_OPCODE exceptions,
* so to be sure, we disable Invalid Opcode FPU exception
* before using FPU stuffs.
*/
usCW = _control87 (0, 0);
usCW = usCW | EM_INVALID | 0x80;
_control87 (usCW, MCW_EM | 0x80);
}
Edit, I get the same result using SSE for floating point math,
cc -Zomf -march=native -mfpmath=sse test.c -o test_libc.exe
H:\tmp>test_libc.exe
cw = 0X7F
cw = 0X7F
cw = 0X7F
cw = 0X7F
5.56268e-309