Re: compiling GSL on digital unix.

[Tim Mooney <mooney at dogbert dot cc dot ndsu dot nodak dot edu>]

In regard to: Re: compiling GSL on digital unix., Mark Galassi said (at...:

>
>Hi Tim and Jon,

Hi Mark!

>[Jon, tell me: what is amazon.com doing with GSL?  I'm fascinated!]
>
>    Tim> I don't think there's an equivalent option in 2.7.2.x, so
>    Tim> code compiled with that version of gcc (including libgsl)
>    Tim> would not be fully IEEE compliant.
>
>What is the downside to that?  Would you recommend that GSL not be
>used in such a case?

First, let me note that I'm not a floating point wizard -- you guys know
more about the intricacies of IEEE floating point (and non-IEEE floating
point as implemented by some wacky hardware).  I am however a very
experienced Unix admin with access to recent Unix implementations from
Compaq, HP, IBM, Sun, and SGI.  My expertise follows that list, in order,
from most to least.  There are probably other people on the list that know
with greater certainty what the implications are relating to the
ieee and ieee-with-inexact options for Digital/Tru64 Unix.

The ieee(3) man page for Tru64 Unix 4.0f has this to say:


  By default, floating-point operations generate imprecise traps for invalid
  operation, division by zero, and overflow errors.  To cause floating-point
  errors to be handled with precise exception faults, or with the signal han-
  dling specified in the IEEE floating-point standard, C language programmers
  should use the -ieee flag to the cc command.  Assembly language programmers
  should use the su suffix on floating-point instruction opcodes and follow
  the software completion rules of the Alpha architecture.  These methods
  allow you to access all features of the IEEE standard except the inexact
  result feature.

  The inexact result feature can sometimes degrade performance, so a dif-
  ferent method is required to enable it.  Assembly language programmers can
  access the inexact result feature by using the sui suffix on floating-point
  instruction opcodes.  C language programmers can access the inexact result
  feature by replacing the -ieee flag to the cc command with the
  -ieee_with_inexact flag.  On some Alpha implementations the inexact result
  feature is implemented by trapping to a software emulator.  Using sui
  floating-point instructions or the -ieee_with_inexact flag might cause a
  significant drop in performance on such implementations.  Because of this,
  you should use the inexact result feature only in those few program state-
  ments where inexact signaling is needed.

  When your code is compiled with ieee or ieee_with_inexact, the delivery of
  all floating-point traps to a user program is disabled by default.  A user
  program can request the delivery of any of the five standard IEEE traps by
  calling ieee_set_fp_control to set the associated flags in the software
  IEEE floating-point control register (fp_control) that control trap
  delivery.  And, in a similar way, a user program can request delivery of an
  invalid operation trap whenever a denormalized operand is used.

  When the IEEE gradual underflow capability (that is, denormalized operands
  and results) is not desired, it can be disabled by specifying one or both
  of the options to map denormalized input operands to zero or to flush
  underflowing results to zero.



This, to me, means that most floating point operations will work exactly as
expected either with or without any of the flags specified to whatever compiler
you happen to be using.  It's the "boundary cases" where inexact numbers will
be returned if you compile without the flags, and the IEEE-specified result
will be returned when you compile with the flag(s).

Furthermore, its my understanding (though I could be wrong -- if someone
knows I am please jump in and correct me) that to use the software controls
for the various IEEE traps *and* to be able to use the read_rnd() & write_rnd()
routines to control the rounding mode via software, you must specify the
additional/special CFLAGS that that GSL's configure is adding for the alpha.
What I mean is that without doing a `-mieee' (to gcc) or `-ieee' (to DEC C),
using the ieee_set_fp_control() call will *not* work.  Similarly, if you
don't specify `-mfp-rounding=node=d' (gcc) or `-fprm d' (DEC C), dynamic
rounding mode (i.e. software controlled) will *not* work.  I don't know how
"spectacularily" it will not work -- if it will just not work or if it
will cause a core dump for example.

Again, my understanding could be flawed, but I think that's how things work.
All it would really take to find out for sure is some floating point torture
test C code that we could run after compiling with various options.  This
would tell us for certain how things work.  I could certainly do the compiling
and testing for this, but I don't think I'm the best guy to necessarily write
the code itself.  I'm just not currently enough of a floating point guru to
know all the things that should be tested (and what the correct answers
are...).

>I think it is a shame to have the code not build because of a bad
>option: it looks cheesy.  I would prefer to have configure warn you
>that the option is not there, and then either go on with a caveat, or
>stop in a clean way.

Ok, I agree.  The only reason I re-coded parts of that section
of configure.in the way I did is because I was essentially expanding what
was already there.  I'll happily add additional code to the original test
and my added code to make sure that the options we're jamming into CFLAGS
actually work.  Note that none of the code that I added is in gsl 0.4.1 --
it's in the post-0.4.1 CVS version.  This means that the problem has always
existed.  Since I was the last one in that section, though, I would be the
best choice for the person to fix it.

It may be a few days before I get a chance to spend some time on this.
If there's an alpha FP guru listening that wants to do the fix, go for it.
Just let me know if you fix it before I get to it, so I don't duplicate
the effort.

>Your note on gcc options for applications that *use* GSL is
>interesting:
>
>    Tim> On more note.  GSL's configure augments CFLAGS for either
>    Tim> Linux or Digital Unix on the alpha because its configure.in
>    Tim> authors know that to get fully compliant IEEE code some
>    Tim> special options are required.  Packages that *use* GSL don't
>    Tim> generally know that, though, and code that uses GSL on the
>    Tim> alpha should be compiled using the same set of rounding and
>    Tim> IEEE-related CFLAGS as GSL itself used.  This means that for
>    Tim> packages that use GSL or software you write yourself that
>    Tim> uses GSL, be sure you compile using the appropriate CFLAGS to
>    Tim> enable soft-controlled rounding and IEEE compliant code.
>
>I have been working on a "gsl-config" program (like gtk-config and
>gnome-config) which would return the options needed to compile and
>link with GSL.  This is important for various reasons, like the fact
>that the libraries are installed into $(prefix)/gsl/libwhatever.a, so
>you need a -L$(prefix)/gsl in the link line.
 
Good idea.  I hate having a million foo-config scripts cluttering up my
local bin directories, but they *are* useful, especially in cases like
this where we don't want to have to educate every `configure.in' author
out there about all the wacky gyrations that may be needed for a particular
platform.  That's what GSL is all about -- hiding the nasty details.

>By the way, what's the worst that happens if -mieee is used to build
>GSL but not the application that invokes GSL?

That I do not know.  It's something that GSL's `make test' should probably
test, though.

BTW, I think I sent Mark and Brian the URL for Compaq's online documentation
(including the Programmer's Guide and the online man pages), but other people
on the list may be interested in looking through them.  They're at

	http://www.unix.digital.com/faqs/publications/pub_page/doc_list.html

The ieee(3) man page would be a good place to start.  The dynamic rounding
control routines are called read_rnd() and write_rnd(), so they would also
be worth a look.

Please let me know if I can help further.  Brian and Mark can expect to
hear from me within the next couple weeks (hopefully some time early next
week, but no promises) with a patch that further improves GSL's configure
for the alpha platform.

(again, I'm not on the list so if there are further responses to this, please
cc me.  Thanks!)

Tim
-- 
Tim Mooney                              mooney@dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J1, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164