This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: underflows, overflows, ... [on Alphas]


>Thus, while it'll be undoubtedly require some work to make this work for
>libf2c, it is not outside the architectural scope of egcs.

I think this statement, and related confusion, came from this text
of mine:

>> Ideally we'd set it up so
>> if you compiled with -mieee, any library calls in the generated code
>> would automatically pick up the corresponding libf2c routines
>> compiled with -mieee, but for now that sort of solution (used by at
>> least some Fortran vendors, I believe) seems to be outside of
>> the architectural scope of egcs.

What did I mean by the above?  Well, my impression is that, with
multi-libbing libf2c and such, to get IEEE behavior (denorms,
infinities, NaNs, etc.) for Alphas, you'd have to do stuff like:

  g77 -mieee -c foo.f
  g77 -mieee -c bar.f
  g77 -mieee foo.o bar.o

Specifically, -mieee when compiling means to produce different
code, while -mieee when linking means to link in a variant of the
relevant libraries that have themselves already been compiled with
-mieee during the compiler-build process.

And, if you know some of your code doesn't need this full behavior,
and you want high performance in it, you'd omit the -mieee while
*compiling* the code, but it'd still link to run-time code in libf2c
that was compiled with -mieee.

What some other Fortran compilation environments is even more flexible:

  g77 -mieee -c foo.f
  g77 -c bar.f
  g77 foo.o bar.o

The above would link -mieee-compiled libf2c routines in only to
references from foo.f, not from bar.f.

This requires name mangling (or much smarter linkers, which we can't
assume) at the very least.  There are other things that must be
accounted for in the design and implementation of the libraries,
so one chunk of source code using static/global variables has only
one copy each of the pertinent ones even when compiled into multiple
chunks of object code that get linked into the resulting executable.

It is my impression that egcs is not architected to accommodate
this more flexible solution.  But multi-libbing libf2c is certainly
worthwhile, as it'll be a big improvement, especially for Alpha users
wanting better-conforming IEEE behavior.

If I'm wrong about any of the above, please correct me!

        tq vm, (burley)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]