Killing two birds with a one-line configuration change

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

RTH rightly takes us to task in his analysis of libstdc++/4150.

The root issue here is related to PR/5820.

If someone on a Linux platform could *please* just try my suggested
fix (which is already used on platforms where it is not even legal to
seek on interactive streams), then this whole seeking performance
problem (and the correctness issue of 5820) will go away entirely for
your port.  The test case from libstdc++/4150 runs in less than twice
the time of a gcc 2.95.2-compiled version on i386-*-freebsd4.5.  This
is still not great but in the past I have estimated for IO-bound code
that it is 2-4 times faster with my seek system call avoidance path
than without it [1].  It is a one-liner.  Add this line:

#define _GLIBCPP_AVOID_FSEEK 1

to your OS config file:

libstdc++-v3/config/os/gnu-linux/bits/os_defines.h

rebuild libstdc++-v3, run testsuite, note zero regressions.  Compare
performance of test before and after my suggestion; unless your libc
is braindamaged in how it buffers (and I do believe that glibc is up
to the task), avoiding these seeks is a huge tradeoff win.  I am not
even asking you to trust me on this point.  Test my configuration
suggestion and see the improvement for yourself...

Will no gcc user that cares about performance on Linux step forward
and test this trivial configuration change so I can commit it for you
before the 3.1 release?  Just report zero test suite regressions and
that it speeds up the case as expected.

libstdc++/5396 demonstrates that Solaris 8 may not configure as
Solaris 2.7 does (for whatever reason).  I can't test this either
since I don't have a Solaris 8 machine handy.

Regards,
Loren

[1] libstdc++-v3 adheres to the standard in ways that affect
performance that libstdc++-v2, as shipped with gcc 2.95.2, did not.
However, architecture changes could perhaps still help.