[PATCH] Update backward/algo.h

[Loren James Rittle]

>> 3. Are we sure we're using a fixed version of gmake when building, or
>>    a non-gmake that doesn't have a matching bug?

> Perhaps Loren could tell us? Or, other people who are not using GNU make?

[It was also asked if anyone builds gcc with srcdir == objdir.  This
response is more directed at that query than the above.  We know many
of our users still want to do this even though we developers know it
is a dumb practice.]

I have systems building gcc mainline and 3.0.X under the following
discipline:

On even days (1) bootstrap gcc against GNU make 3.79.1 with srcdir !=
objdir (send make check report to public list); (2) bootstrap gcc
against GNU make 3.79.1 with srcdir == objdir (send make check report,
difference from above and any installed file differences to me only).

On odd days (3) repeat 1 using BSD make instead of GNU make; (4)
repeat 2 using BSD make instead of GNU make.

The check of installed files compares all non-binary files for an
exact match and also reports any missing binaries.

Unless something really strange happens, the test cycle never
exercises the INTR issue with GNU make.  Even if it were to have
happened, the daily source update would have corrected the problem.

Last I checked, tests (3) and (4) are currently broken when
--enable-libgcj was provided to top-level configure or is the system
default.

Extra bogus files are still installed in cases (2) and (4).  Last I
looked closely, libstdc++-v3/include/Makefile.in was the only part of
gcc with this issue.  None of the extra stuff installed would seem to
affect anything in practice (this was not always true) but I have
meant to finish the cleanup job at some point.

BTW, I prefer to stay out of the rest of the argument (although I am
sure I have seen Nathan's issue in practice but I sure don't remember
which version of GNU make I was using nor do I have a test case ;-).

Regards,
Loren
-- 
Loren J. Rittle
Senior Staff Software Engineer, Distributed Object Technology Lab
Networks and Infrastructure Research Lab (IL02/2240), Motorola Labs
rittle@rsch.comm.mot.com, KeyID: 2048/ADCE34A5, FDC0292446937F2A240BC07D42763672