Floating exceptions in G77 on WIN95
actprime
ian@actprime.idps.co.uk
Wed Mar 29 10:46:00 GMT 2000
I am usingÃÂ :-
g77 version 2.95.2 19991024 (release) (from FSF-g77 version 0.5.25 19991024
(rel
ease))
Driving: C:\GCC-29~1.2\BIN\G77.EXE -v -c -xf77-version /dev/null -xnone
G77.EXE: /dev/null: No such file or directory
Reading specs from C:\GCC-29~1.2\BIN\..\lib\gcc-lib\i386-mingw32\2.95.2\specs
gcc version 2.95.2 19991024 (release)
Microsoft Windows 95ÃÂ 4.00.950 CÃÂ IE 5 5.00.2314.1003
Fortran options :-
g77ÃÂ -fexceptions -fhandle-exceptions -fugly-init -mno-align-double
-c -g -w -fvxt -fno-automatic
ÃÂ
ÃÂ
I am putting together a fairly large engineering program but I keep
on encounteringÃÂ Floating Point exceptions which result in print-outs
similar to this:-
ÃÂ ÃÂ ÃÂ ÃÂ 9ÃÂ ÃÂ ÃÂ 9ÃÂ $$ LOCN HOLES DRILL
NOW FEEDS OUT OF HOLESÃÂ (WAS RAPID)
ÃÂ ÃÂ ÃÂ 10ÃÂ ÃÂ 10ÃÂ L1 =LINE/20,30,200,100
ÃÂ ÃÂ ÃÂ ÃÂ L1 (ÃÂ ÃÂ 0 )ÃÂ ÃÂ ÃÂ LINEÃÂ
4ÃÂ ÃÂ ÃÂ -1.#IND00ÃÂ ÃÂ ÃÂ -1.#IND00ÃÂ ÃÂ ÃÂ ÃÂ
0.000000ÃÂ ÃÂ ÃÂ -1.#IND00
ÃÂ ÃÂ ÃÂ 11ÃÂ ÃÂ 11ÃÂ C1=C/20,30,200
ÃÂ ÃÂ ÃÂ ÃÂ C1 (ÃÂ ÃÂ 0 )ÃÂ CIRCLEÃÂ 7ÃÂ ÃÂ ÃÂ
20.000000ÃÂ ÃÂ ÃÂ 30.000000ÃÂ ÃÂ ÃÂ ÃÂ 0.000000ÃÂ ÃÂ ÃÂ ÃÂ
0.000000ÃÂ ÃÂ ÃÂ ÃÂ 0.000000ÃÂ ÃÂ ÃÂ ÃÂ 1.000000ÃÂ ÃÂ
200.000000
ÃÂ ÃÂ ÃÂ 12ÃÂ ÃÂ 12ÃÂ PSIS/0,0,1,20
ÃÂ NESTED (ÃÂ ÃÂ 0 )ÃÂ ÃÂ PLANEÃÂ 4ÃÂ ÃÂ ÃÂ ÃÂ
0.000000ÃÂ ÃÂ ÃÂ ÃÂ 0.000000ÃÂ ÃÂ ÃÂ ÃÂ 1.000000ÃÂ ÃÂ ÃÂ
20.000000
ÃÂ ÃÂ ÃÂ 13ÃÂ ÃÂ 13ÃÂ FROM/200,200,100
ÃÂ ÃÂ ÃÂ 14ÃÂ ÃÂ 14ÃÂ GO/C1
ÃÂ ÃÂ ÃÂ 15ÃÂ ÃÂ 15ÃÂ PRINT/3,ALL
ÃÂ ÃÂ ÃÂ ÃÂ L1 (ÃÂ ÃÂ 0 )ÃÂ ÃÂ ÃÂ LINEÃÂ ÃÂ
4ÃÂ ÃÂ ÃÂ -1.#IND00ÃÂ ÃÂ ÃÂ -1.#IND00ÃÂ ÃÂ ÃÂ ÃÂ
0.000000ÃÂ ÃÂ ÃÂ -1.#IND00
ÃÂ ÃÂ ÃÂ ÃÂ C1 (ÃÂ ÃÂ 0 )ÃÂ CIRCLEÃÂ ÃÂ
7ÃÂ ÃÂ ÃÂ 20.000000ÃÂ ÃÂ ÃÂ 30.000000ÃÂ ÃÂ ÃÂ ÃÂ
0.000000ÃÂ ÃÂ ÃÂ ÃÂ 0.000000ÃÂ ÃÂ ÃÂ ÃÂ 0.000000ÃÂ ÃÂ ÃÂ ÃÂ
1.000000ÃÂ ÃÂ 200.000000
ÃÂ
ÃÂ
I have read the documentation from g77_20.htmÃÂ ÃÂ viz :--
" Floating-point Exception Handling
The gcc backend and, consequently, g77, currently provides no general
control over whether or not
floating-point exceptions are trapped or ignored. (Ignoring them
typically results in NaN values being
propagated in systems that conform to IEEE 754.) The behaviour is
normally inherited from the
system-dependent startup code, though some targets, such as the
Alpha, have code generation options which change the behaviour.
Most systems provide some C-callable mechanism to change this; this
can be invoked at startup using gcc's
constructor attribute. For example, just compiling and linking the
following C code with your program will
turn on exception trapping for the "common" exceptions on an x86-based
GNU system:
#include <fpu_control.h>
static void __attribute__ ((constructor))
trapfpe ()
{
ÃÂ __setfpucw (_FPU_DEFAULT &
ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ
~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM));
}
A convenient trick is to compile this something like:
gcc -o libtrapfpe.a trapfpe.c
and then use it by adding `-trapfpe' to the g77 command line when
linking.ÃÂ "
ÃÂ
HOWEVERÃÂ I do not have either fpu_control.hÃÂ or _setfpucw
in my libraries.
ÃÂ
Can you please advise me how to avoid handle FP exceptions.
ÃÂ
ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ ÃÂ
Ian Hacking , Lancaster, England
More information about the Gcc-bugs
mailing list