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: Bug with g77 and -mieee on Alpha Linux


>In the end, it is about great software that users like and respect.

Great software doesn't crash and burn on input that is wrong in highly
predictable ways.  g77 *does*, in effect, do that.

>Personally I don't have much of an opinion if gofast or becorrect
>should be the default.

If only that were the choice.  In fact, the choice here is between bewrong
and beabitslowerthantheoreticallypossible.  After all, even Toon agrees
that too many people are writing Fortran code without knowing what they're
doing.  That number is, IMO, vastly higher if we choose Toon's model than
if we choose defaults consistent with what the industry, itself, has
proposed, debated, and standardized upon (and which at least *some*,
if not all, other Fortran compiler have agreed upon as well).

The wonderful thing about choosing Toon's approach is that, we can then
go rewrite all the intrinsics (such as the transcendentals) to use faster
methods that don't bother to compute correct results for inputs beyond
the "accepted" range.  After all, that's what the code Toon works on *does*
-- it doesn't bother calling SIN, COS, etc., it employs faster in-line
versions that don't worry about those bothersome corner cases.

If we decide to go whole-hog for Toon's approach, we can replace, wholesale,
our SIN/COS/TAN and other intrinsics with similar kinds of open-coded
replacements.

So it's not that I don't respect that approach -- I do.  I just happen
to think that, in practice, the *audience* for that approach -- defined
as the audience that *knows what they're doing* -- is vanishingly small
compared to the audience for "pedestrian", straightforward, robust
IEEE 754 support.

After all, Toon represents the sort of audience I claim does not *need*
g77 to default to "gofast" mode -- I mean, they've already rewritten
their code to inline transcendentals, to avoid INTEGER*8 (so it could
run on $$$ Fujitsu iron), and so on.  To me, it's hard to understand
why it's so painful for that audience to specify `-mno-ieee' or some
such thing, but apparently it is.

Also, I keep seeing the claim that, effectively, nobody should be using
floating-point (at least in Fortran) unless they're solving one of a
particular set of problems that have been Declared Properly Solved Using
Limited Range (DPSULR) by people like Toon.

What I *don't* know is whether that claim is true.  I certainly see plenty
of people who, like Toon, seem to know a lot more than I do about how
Fortran is actually used in the field, who disagree that DPSULR problems
are the only ones worth using floating-point for, and who claim the
*other* problems rely on the full range and support of IEEE 754 being
available.

It is also non-trivial for me to just say "well, I'll pick *my* defaults
for g77, let someone else pick whatever *they* want", because, without
the support of much of the GCC team (Toon being on the Steering Committee,
but not me!), it'll be difficult to get people to help support things
like 80-bit spills and -mieee working correctly.

Similarly, if we *don't* thoroughly discuss and document the issues,
and instead Toon and others simply capitulate to my feelings, the
result could be that g77 becomes useless to most of its audience because
it no longer defaults to what they see as "gofast" mode, or doesn't
properly implement it (as is apparently the case with -mno-ieee being
the default, vis-a-vis issues I raised earlier).

In other words, we barely have enough resources to support one incarnation
of g77.  It's not clear we'd have nearly enough to support two or three.

And, my having to support the conflicting requirements of multiple camps
of Fortran users has been painful enough to deal with over the years
(e.g. backslashes in character constants).  This is yet another very
difficult schism, amplified by the fact that the very users Toon handwaves
as unworthy of g77 (since think they need full IEEE 754 support) are
the ones *most* likely to submit bug reports before they do full
investigations of the problem.  So if we choose Toon's camp, we get
(as we've been getting, only worse as g77 improves and, hopefully, becomes
more popular) bazillions of not-quite-right bug reports; if we choose
overall robustness, we get hardly any by comparison, since g77 Just Works,
and the Toon-like experts already know how to use compiler options to get
speed *and* how to investigate code generation to find bugs, before
complaining about them.

        tq vm, (burley)


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