Re: "make check" failure in fixincludes

[Loren James Rittle <rittle at latour dot waar dot labs dot mot dot com>]

In article <4148C4CA.52FC463F@veritas.com>,
Bruce Korb<bkorb@veritas.com> writes:

>> It looks like there's a "make check" failure in fixinclude that's
>> possibly related to your 2004-09-13 check-in.  Unfortunately, its
>> not immediately clear what the problem is...
[...]
>> I'm not sure if there's a bad interaction between the two fixes;
>> freebsd_gcc3_breakage_check and freebsd_gcc4_breakage_check?

Argh!  Gerald, is there some room in that dog house I sent you to the
other day?

> The "tests/base" tree should be a copy of "tests/res",
> whereas this looks like text compared against what one would
> find in the "tests/inc" directory.  The three directories:

> tests/base  --  what the files ought to look like after fixing
> tests/inc   --  constructed-on-the-fly files that need to be fixed
> tests/res   --  the results of the fix process

> The fixinclude developer needs to understand any differences
> between tests/base and tests/res.  If these differences are valid
> (i.e. are expected results of a new fix), then move modified files
> from tests/res to tests/base and commit them.

> A very simple rule:

>    DO NOT EVER HAND EDIT FILES IN tests/base !!!

Bruce,

Well, I do hope that you'd agree that hand editing that file was a
slightly better idea than blindly copying over a res file without any
thought but I'm indeed guilty as charged.  I see how I have violated
rule 5 of the README, section GCC MAINTAINER INFORMATION.  Sorry,
there was no such rule when freebsd_gcc3_breakage was added back
around "Wed, 21 Feb 2001".  My clue meter should have fired when you
asked me to update a strange file.  Anyways, here is the analysis of
the failure that Roger noted:

The freebsd_gcc3_breakage fix has a bypass rule which is only
triggered once the new test case for freebsd_gcc4_breakage is added.
I.e. there appears to be NO way to properly test both fixes against
the same input file and get the expected output for each case.  It is
true that freebsd_gcc3_breakage will never fire if
freebsd_gcc4_breakage could fire.  This also matches the history the
header being fixed.  In FreeBSD 4, the system retains exactly one
header which will fail when the gcc major version number was bumped.
That issue appears gone in FreeBSD 5 (or at least moved to another file).

Under the tested theory that the fixes are both correct (they are when
the context is the actual system header) and that the old fix hasn't
been touched for a long while, the correct path forward would appear
to be accepting the new res file as the baseline over my hand-crafted
expected outcome.  (Asking with tail between legs:) OK to install?

Sorry to be so long-winded but let this be a lesson to those that
might taunt Gerald in the future. ;-)  Final thought: if fixinclude
were to report regressions *precisely* as the rest of gcc, then I
wonder if I would have allowed myself to make this same mistake?
There is something about "FAIL: fixincludes tests/base/sys/cdefs.h"
that is lost on me in a sea of expected (on BSD machines) diff output.

Regards,
Loren

	* tests/base/sys/cdefs.h: Accept new baseline.

Index: tests/base/sys/cdefs.h
===================================================================
RCS file: /cvs/gcc/gcc/fixincludes/tests/base/sys/cdefs.h,v
retrieving revision 1.2
diff -c -r1.2 cdefs.h
*** tests/base/sys/cdefs.h	14 Sep 2004 03:41:10 -0000	1.2
--- tests/base/sys/cdefs.h	16 Sep 2004 01:03:41 -0000
***************
*** 10,16 ****
  
  
  #if defined( FREEBSD_GCC3_BREAKAGE_CHECK )
! #if __GNUC__ == 2 && __GNUC_MINOR__ >= 7 || __GNUC__ >= 3
  #endif  /* FREEBSD_GCC3_BREAKAGE_CHECK */
  
  
--- 10,16 ----
  
  
  #if defined( FREEBSD_GCC3_BREAKAGE_CHECK )
! #if __GNUC__ == 2 && __GNUC_MINOR__ >= 7
  #endif  /* FREEBSD_GCC3_BREAKAGE_CHECK */