OS2 World Community Forum
OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: agena on September 04, 2014, 11:40:26 am
-
Hello,
I am currently porting an interpreter to eCS 2.2 using various GCC compilers (4.4.x, 4.5.x, 4.7.x)
kindly provided by Paul Smedley. I run eCS on Sun VirtualBox 4.3.12.
In my regression tests, I notice various SIGFPE crashes obviously issued via libc065 when trying
to call C's trunc, cosh, and sinh functions (thus far). Is this a known issue with eCS/GCC ?
The interpreter heavily relies on the use of doubles in numerical loops, etc. Although it never has
been fast on my late native OS/2 Warp 4 machine many years ago, the interpreter is running
unbearably slow now on eCS. When compiling, I use the following switches:
os2static:
$(MAKE) all MYCFLAGS="-O2 -static-libgcc -fomit-frame-pointer -D__ST_MT_ERRNO__ (+ some Agena/Lua non-numerical switches)"
Is there an approriate switch to speed up double arithmetic ?
Thank you,
Alex
-
The problem is a bug somewhere in the PMSHELL where the floating point control word is not restored after the DLL enables FPU exceptions. There is a libc bug open to add a workaround to libc and hopefully it'll be fixed there.
For now something like this usually works (multi-threaded apps may need more complex solutions)
int main(int argc, char **argv)
{
+#ifdef __i386
+ short fcr;
+ __asm__ volatile ("fstcw %0 \n"
+ "or $63, %0 \n"
+ "fldcw %0 \n"
+ : "=m"(fcr));
+#endif
+
-
Dave,
gosh ! Your fix works great - no FPU exceptions any longer and the interpreter
has become super-fast now, as well.
Thank you very much,
Alex
-
Hello,
I had been wondering last night how anybody can port current OpenSource projects
to eCS with this very substantial (libc06*.dll ?) bug.
Without Dave's help, I would have surrendered.
Alex
-
It's an OS/2/eCS bug, doesn't affect my Warp v4 install. It only affects programs that do some types of floating point which is surprisingly few and workarounds such as I posted have to be added. Some such as Mozilla can get complex making sure that every thread doesn't sigfpe.
BTW, have you looked at exceptq http://hobbes.nmsu.edu/download/pub/os2/dev/util/exceptq71-dev.zip (http://hobbes.nmsu.edu/download/pub/os2/dev/util/exceptq71-dev.zip), catches crashes and outputs some nice debugging info.