This is the mail archive of the gcc-patches@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]
Other format: [Raw text]

Re: "make check" failure in fixincludes


Loren James Rittle wrote:
> 
> 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?

It better be a roomy dog house, 'cuz we all gotta go there some times.
Don't be too hard on yourself.

> 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

Well, that _is_ why I wrote:

> 5.  Go into the fixinc build directory and type, "make check".
>     You are guaranteed to have issues printed out as a result.
>     Look at the diffs produced.  Make sure you have not clobbered
>     the proper functioning of a different fix.  Make sure your
>     fix is properly tested and it does what it is supposed to do.

whereby you were supposed to notice that the gcc3_breakage_check
failed.  Then you get to decide what to do.

> 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?

The fixinclude make check results are deliberately not incorporated
into the regular "make check".  It only ever needs to be done when
someone is messing with it, and that is fairly uncommon.

> 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.

Please suggest a better way to report the issue  :)

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

For the time being, fine.  However, does this work?  :)

/*
 *  Between 8/24/1998 and Sep/2004, FreeBSD system headers presume
 *  neither the existence of later versions of GCC, nor its exact
 *  feature set yet break (by design?) when __GNUC__ progresses.
 */
fix = {
    hackname  = freebsd_vers_breakage;
    mach      = *-*-freebsd*;
    files     = sys/cdefs.h;
    select    =  '^#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7$'
             '|' '^#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7 \|\| __GNUC__ == 3$';
    bypass    = '__GNUC__[ \t]*(>=[ \t]*[3-9]|>[ \t]*2)';
    c_fix     = format;
    c_fix_arg = '#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7 || __GNUC__ >= 3';
    test_text = '#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7' "\n"
                '#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7 || __GNUC__ == 3';
};


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