Signalling NaNs for floating point initialization?

Signalling NaNs for floating point initialization?

[Thomas Koenig]

One of the most useful options on an SGI Fortran compiler I've worked
with some years ago was to set all floating point variables to
signalling NaNs upon startup of a program, which helped a lot in
converting old code and in finding quite a few bugs in new ones.

What do you think about implementing this in g77?
-- 
Thomas Koenig, Thomas.Koenig@ciw.uni-karlsruhe.de, ig25@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.

Re: Signalling NaNs for floating point initialization?

[Dave Love]

>>>>> "TK" == Thomas Koenig <ig25@mvmap66.ciw.uni-karlsruhe.de> writes:

 TK> One of the most useful options on an SGI Fortran compiler I've
 TK> worked with some years ago was to set all floating point
 TK> variables to signalling NaNs upon startup of a program, which
 TK> helped a lot in converting old code and in finding quite a few
 TK> bugs in new ones.

Indeed, for values of `One of the most useful options' equal to `about
the only good thing', at least as of a couple of years ago...

 TK> What do you think about implementing this in g77?

AFAIR, it's on the todo list and definitely a good idea.  It's
probably straightforward for scalars by analogy with
-finit-local-zero, but not for arrays; the backend doesn't seem to
provide a facility for initializing aggregates to a repeating bit
pattern other than zeroes (presumably reflecting what assemblers give
you).

Craig had some objection to work on this which I can't recall but
perhaps he can; it was probably to doing only part of the job,
i.e. scalars, which probably aren't the main source of such bugs.

Re: Signalling NaNs for floating point initialization?

[Jeffrey A Law]

  In message < rzq3e6efv6r.fsf@djlvig.dl.ac.uk >you write:
  > -finit-local-zero, but not for arrays; the backend doesn't seem to
  > provide a facility for initializing aggregates to a repeating bit
  > pattern other than zeroes (presumably reflecting what assemblers give
  > you).
But handling this is a relatively straightforward extension to clear_storage.  


jeff

Re: Signalling NaNs for floating point initialization?

[Dave Love]

>>>>> "Jeff" == Jeffrey A Law <law@upchuck.cygnus.com> writes:

 Jeff> But handling this is a relatively straightforward extension to
 Jeff> clear_storage.

Given sufficient guidance, I can probably volunteer.  g77 doesn't
currently use clear_storage AFAICT, but I'm highly ignorant of the
backend stuff.

(This should be useful for all languages, of course.)

Re: Signalling NaNs for floating point initialization?

[Jeffrey A Law]

  In message < rzq1zlxdwsf.fsf@djlvig.dl.ac.uk >you write:
  > >>>>> "Jeff" == Jeffrey A Law <law@upchuck.cygnus.com> writes:
  > 
  >  Jeff> But handling this is a relatively straightforward extension to
  >  Jeff> clear_storage.
  > 
  > Given sufficient guidance, I can probably volunteer.  g77 doesn't
  > currently use clear_storage AFAICT, but I'm highly ignorant of the
  > backend stuff.
clear_storage happens implicitly for some initializers and for some calls
to memset.  See expr.c

Jeff

Re: Signalling NaNs for floating point initialization?

[Craig Burley]

>Craig had some objection to work on this which I can't recall but
>perhaps he can; it was probably to doing only part of the job,
>i.e. scalars, which probably aren't the main source of such bugs.

Maybe, but I can't recall, other than, long ago when this was first
suggested, I liked it (and wrote it down), but was probably very
nervous about how such changes would affect the "back end" of the g77
front end, especially if they required changes in the gcc/g77 back end
itself.

Now that g77 is egcs-ized, I feel a lot less "ownerous" about it, and
don't mind if others try things out.  It's a lot easier to approve
other peoples' patches, for example, when I don't have to do all the
work myself to apply them, do basic testing, document them, package
up alpha releases, upload, and announce them...and undo it all if
the patches don't work out somehow!

        tq vm, (burley)