Re: [jwe@bevo.che.wisc.edu: Crashing after complex division by zero]

[Toon Moene <toon@moene.indiv.nluug.nl>]

craig@jcb-sc.com wrote:

> Enclosed is a bug report against libF77.  I'm not sure how valid the
> complaint is, or what all the implications of making the recommended
> change are.  I'm pretty sure we won't be making any g77-specific patches
> to libf2c (in what we call libg2c) anymore, except in specific instances,
> such as when we're pretty sure you're going to make the same bug-fix
> shortly anyway -- definitely not the case here!

Well, you will be surprised to hear this from me, but it is a correct
move in the direction of making libF77 IEEE-conformant (so it is a long
term bug-fix).

In fact, because I anticipated the interest in IEEE-conformant
programming, I already designed my open-coded complex division in
optabs.c likewise.

[ducks]

My line of reasoning at that time was:

1. I don't know how to code
	sig_die("complex division by zero", 1);
   in optabs.c

2. However, I won't have to, when I adhere to the following principle:
   The division that's part of complex division will abort itself,
   iff the CPU is placed in a mode that enforces 
   trap-on-divide-by-zero and the trap leads to an abort.

3. This means that complex-divide-by-zero won't abort on IEEE conformant
   hardware by default, but we should change that silly default
   anyway.

[ducks 2]

[ sprinkle the above with smiley's liberately ]

> Also, I'll note that, as of gcc 2.95 aka g77 0.5.25, libg2c's c_div and
> z_div routines aren't used by default anymore.  But they're still used
> if the user compiles with the `-Os' (optimize for space) option, so we're
> still interested in keeping them current vis-a-vis netlib libf2c.

Of course, that means that programs compiled with -Os do not perform the
same computation as those compiled with other options.  I'm sorry I
forgot to point that out.

John Eaton's Octave example points out why this do-not-abort-on-complex-
divide-by-zero can be useful (especially when coupled to "passing the
buck up"):  Octave could deliver a meaningful message to the user,
instead of dumping core itself; or it could enable a user program to
receive the trap [I do not really know if that can be done in Octave's
language - perhaps John can point that out].

Cheers,

-- 
Toon Moene (toon@moene.indiv.nluug.nl)
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Phone: +31 346 214290; Fax: +31 346 214286
GNU Fortran: http://world.std.com/~burley/g77.html