Re: good news and bad news on floating-point problems

[Jesse Goldman <goldman@phys.ksu.edu>]

I've been following this thread with some interest as I've been trying to
compile a large piece of legacy code on an alpha with the same results
that have been mentioned. I've played around with the following flags to
see which one or which combination would produce the least number of
floating exceptions:

-mieee

-mieee-with-inexact

-mfp-trap-mode=u

-mfp-trap-mode=sui -mtrap-precision-i

None of them have taken care of all the floating point exceptions,
notably, those caused by "dlog(number<=0.d0)" which I've had to fix by
hand in the code. Another interesting (but frustrating) issue is that many
routines, both fortran and C, refuse to compile with the -mieee type
options. Attempts result in errors like:

g77 -c -O -fno-automatic -fno-second-underscore -fugly-complex -g
-mieee-with-inexact    -I/root/cernlib98/src/pawlib/paw
-I/root/cernlib98/src/paw -I/root/cernlib98/src/paw/code
-I/root/cernlib98/src/include  -DCERNLIB_LINUX -DCERNLIB_UNIX
-DCERNLIB_LNX   -o archive/pafeyn.o pafeyn.F
pafeyn.F: In subroutine `pafeyn':
pafeyn.F:274: internal error--unrecognizable insn:
(insn 1082 1081 1083 (set (reg:DF 452)
        (le:DF (float_extend:DF (reg:SF 448))
            (float_extend:DF (reg:SF 449)))) -1 (insn_list 1077 (insn_list
1081 (nil)))
    (expr_list:REG_DEAD (reg:SF 448)
        (nil)))
../../gcc/toplev.c:1138: Internal compiler error in function fatal_insn

Sometimes, I can avoid this by subtituting a -mfp-trap-mode=u for the
-mieee option, but then it doesn't catch all the exceptions! For the time
being, I've resigned myself to fixing such problems manually (working
under the assumption that "good" code shouldn't try to take logarithms of
0!) but this is slow. Does anyone know what these errors mean?

Thanks,

J. Goldman


--  
To UNSUBSCRIBE, email to debian-alpha-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org