gcc/Makefile.in targets 'compare' and 'gnucompare' behave differently

[Phil Edwards]

While I was adding *strap targets to the top-level Makefile, I saw that
gcc's Makefile has a "gnucompare" target for every "compare" target,
which is meant to cut down on overhead.  So I changed the top-level
*strap rule to run the gnucompare targets instead of the normal compare.
(This was going to remain a local change, of course.)

They behave differently when a .o file is only present in one of the stages
being compared:  compare fails safely, gnucompare does not.  And on the
next scheduled run of my builder/regression tester after I made the change,
'make gnucompare' reported differences (in conftest.o, go figure), and
then most embarassingly compared changelogs and accused David Edelsohn of
breaking the build.  Silly autocrasher.


The compare target does this:

  for file in *.o; do \
    tail +16c ./$file > tmp-foo1; \
    tail +16c stage$stage/$file > tmp-foo2 \
      && (cmp tmp-foo1 tmp-foo2 > /dev/null 2>&1 || echo $file differs >> .bad_compare) || true; \
  done

and gnucompare does this:

  for file in *.o; do \
    (cmp --ignore-initial=16 $file stage$stage/$file > /dev/null 2>&1 || echo $file differs >> .bad_compare) || true; \
  done

Now imagine a .o in the current directory, but not in the stage(whatever)
directory.  You can see that the 'compare' fragment will execute the
'true' command, but the 'gnucompare' fragment will always send a line to
.bad_compare on even an innocent failure.  Eeek.

As far as error messages go, 'compare' does print

  tail: stage2/conftest.o: No such file or directory

for the second tail command, but 'gnucompare's errors are bitbucketed.
It prints the same error and exits nonzero when run by hand.


There's a gazillion simple ways to fix this, all equivalent as far
as I'm concerned, but you guys are the build machinery maintainers.
Any preferences?  How about

  for file in *.o; do \
    test -f stage$stage/$file && (cmp --ignor...bad_compare) || true; \
  done


Phil

-- 
I would therefore like to posit that computing's central challenge, viz. "How
not to make a mess of it," has /not/ been met.
                                                 - Edsger Dijkstra, 1930-2002