Top Level Autoconfiscation Status

[Nathanael Nerode <neroden at doctormoo dot dyndns dot org>]

Take two, no attachments.

Autoconfiscation?  Well, it seems to work.

This is a long message.  Please skip the parts which don't relate to
your area of interest/expertise, and read the other parts. :-)

Just-GCC native bootstrap on i686-pc-linux-gnu builds.  Couldn't 'check'
this one because it's *just* gcc, no dejagnu.

Ubertree cross-compiler to powerpc-eabisim builds.  make check mostly
works; unexpected failures are below.

* zlib has no check target, so I have to somehow leave it out
* mmalloc doesn't check properly (it has an entirely defective rule), so
I have to leave it out. This is probably because of a bug in the old
Makefile which prevented mmalloc from being checked by 'make check' --
it's a substitution error, 'check-mmcheckoc' for 'check-mmalloc'.

binutils has one unexpected failure
-----------------------------------
* 'readelf -wi'.
I doubt that this is due to my changes, though verification would be
nice.

gdb has quite a lot of unexpected failures: 
-------------------------------------------
*  gdb.base/call-rt-st.exp: print print_five_chats(*five_char)'
*  gdb.base/callfuncs.exp: p t_float_values2(3.14159,float_val2)
*  gdb.base/callfuncs.exp: call inferior func with struct -- returns
float
*  gdb.base/callfuncs.exp: backtrace at nested call level 2
*  gdb.base/callfuncs.exp: backtrace at nested call level 3
*  gdb.base/callfuncs.exp: backtrace at nested call level 4
*  gdb.base/callfuncs.exp: backtrace after finish from nested call level 4
*  gdb.base/callfuncs.exp: backtrace after finish from nested call level 3
*  gdb.base/commands.exp: continue with watch
*  gdb.base/ending-run.exp: step out of main (at end 2)
*  gdb.base/finish.exp: finish from float_func
*  gdb.base/funcargs.exp: print *stp
*  gdb.base/printcmds.exp: ptype &*"foo"
*  gdb.base/recurse.exp: second instance watchpoint deleted when leaving
scope
*  gdb.base/recurse.exp: continue to first instance watchpoint, second
time
*  gdb.base/recurse.exp: first instance watchpoint deleted when leaving
scope
*  gdb.base/relocate.exp: static variables have different addresses
*  gdb.base/return2.exp: char value returned successrully
*  gdb.base/return2.exp: short value returned successrully
*  gdb.base/return2.exp: float value returned successrully
*  gdb.base/structs.exp: p fun5()
*  gdb.base/structs.exp: p fun6()
*  gdb.base/structs.exp: p fun7()
*  gdb.c++/cplusfuncs.exp: print &'hairyfunc5'
*  gdb.c++/cplusfuncs.exp: print &'hairyfunc6'
*  gdb.c++/cplusfuncs.exp: print &'hairyfunc7'
*  gdb.c++/local.exp: ptype Local (gdb/483)
*  gdb.c++/local.exp: ptype InnerLocal::NestedInnerLocal (gdb/482)
*  gdb.c++/ovldbreak.exp: continue to bp overloaded : int
*  gdb.c++/ovldbreak.exp: continue to bp overloaded : (unsigned|unsigned
int)
*  gdb.c++/ovldbreak.exp: continue to bp overloaded : long
*  gdb.c++/ovldbreak.exp: continue to bp overloaded : unsigned long
*  gdb.c++/templates.exp: ptype T5<int>
*  gdb.c++/templates.exp: ptype t5i
*  gdb.c++/templates.exp: constructor breakpoint (bad menu choices)
*  gdb.c++/templates.exp: destructor breakpoint
*  gdb.c++/templates.exp: print Foo<volatile char *>::foo
*  gdb.c++/templates.exp: print Garply<Garply<char> >::garply
*  gdb.mi/mi-console.exp: Hello message (known bug)
*  gdb.mi/mi-stack.exp: stack args listing 0
*  gdb.mi/mi-stack.exp: stack args listing 1
*  gdb.mi/mi-var-child.exp: get number of children of
struct_declarations.s2.u2.u1s1
*  gdb.mi/mi-var-child.exp: create local variable weird
*  gdb.mi/mi-var-cmd.exp: update all vars: all now out of scope
*  gdb.mi/mi-var-cmd.exp: delete var
*  gdb.mi/mi-var-display.exp: create local variable weird
*  gdb.mi/mi-var-display.exp: get children local variable weird
*  gdb.mi/mi-watch.exp: wp out of scope (2)
*  gdb.mi/mi0-console.exp: Hello message (known bug)
*  gdb.mi/mi0-stack.exp: stack args listing 0
*  gdb.mi/mi0-stack.exp: stack args listing 1
*  gdb.mi/mi0-var-child.exp: get children of
struct_declarations.s2.u2.u1s1
*  gdb.mi/mi0-var-child.exp: create local variable weird
*  gdb.mi/mi0-var-cmd.exp: update all vars: all now out of scope
*  gdb.mi/mi0-var-cmd.exp: delete var
*  gdb.mi/mi0-var-display.exp: create local variable weird
*  gdb.mi/mi0-var-display.exp: get children local variable weird
*  gdb.mi/mi0-watch.exp: wp out of scope (2)

I need to figure out if any of these are my fault and if so where to
look for the source of the problems; I don't have any clue where to
look.  I'm actually wondering if some of these are spurious, since
subsequent tests which sound like they should be dependent, succeed. :-P
It also looks suspiciously like there are some duplicate tests in here.
I'm also wondering how many of these tests are expected to work in a
cross environment. :-P

sid has some unexpected failures:
---------------------------------
*  assert tx
*  deassert tx
(apparently related to trying to open /dev/audio)
* read identification for drive 0 - wait 06 0x08 0x08 - unmapped 0
* read identification for drive 0
* read identification for nonexistent drive 1 - wait 06 0x01 0x01 -
unmapped 0
* read identification for nonexistent drive 1
* write first sector of drive 0 - wait 06 0x08 0x08 - unmapped 0
* write first sector of drive 0 - wait 06 0x01 0x00 - unmapped 0
* write first sector of drive 0
* write second sector of drive 0 using shorts - wait 06 0x08 0x08 -
unmapped 0
* write second sector of drive 0 using shorts - wait 06 0x01 0x00 -
unmapped 0
* write second sector of drive 0 using shorts
* copy CHS sectors 0,1 on drive 0 TO LBA sectors 1,0 on drive 1 - wait
06 0x08 0x08 - unmapped 0
* copy CHS sectors 0,1 on drive 0 TO LBA sectors 1,0 on drive 1 - wait
06 0x01 0x00 - unmapped 0
(the last two appear four times each!)
* copy CHS sectors 0,1 on drive 0 TO LBA sectors 1,0 on drive 1
* acquire mapper bus handle
* set memory state dump
* reread junk from memory after restore - mismatch @3 - 192 vs 0
* reread junk from memory after restore
* reload sparse (RLE) snapshot
* save & restore large memory snapshot - ok bad_value
I don't even know what these mean, but I still doubt they have anything
to do with me.

gcc has few unexpected failures
-------------------------------
* gcc.c-torture/compile/20001226-1.c, -O3 -g
Timed out, so I don't think it has anything to do with my changes.
* Some other tests fail which were already failing according to geoff's
regression tester.

libstdc++-v3 has few unexpected failures
----------------------------------------
* 26_numerics/c99_classification_macros_c.cc (test for excess errors)
I don't see how this could have anything to do with me.
* Some other tests fail which were already failing according to geoff's
regression tester.

newlib has some unexpected failures
-----------------------------------
* Failed to compile UTF-8.c
* Failed to compile atexit.c
* Failed to compile
/home/neroden/gnu/both_auto/newlib/testsuite/newlib.string/tstring.c
* /home/neroden/gnu/both_auto/newlib/testsuite/newlib.string/tstring.c
Same errors showed up in the alternate newlib subdirs
"und","le","ca","le/und","nof","nof/und","nof/ca","nof/le","nof/le/und",
whatever the heck those are.

Again, I doubt this has anything to do with me.

---------------------

I'm going to do an ubertree native build & check as soon as I free up
enough space on my hard drive. :-P  This is not a fun test platform,
since it's slow and has fairly limited test space.

I'm wondering what the correct thing to do next is.

Obviously a *lot* more configurations should be tested.  I only have
one hardware configuration, so I'm not really sure how to test the
build!=host ones.  I'm also getting kind of burned out on testing;
getting other people to test their favorite configurations would
certainly help, even if they are configurations I could test.  There are
also other things to test (I might possibly have broken weird targets
like taz and gcc-no-fixincludes).

I don't know if there's any chance of this getting into mainline for
gcc 3.2; it is a large change, although it affects very few files and I
think it's quite stable.  I have no objections to aiming for 3.3 phase
1...

*except* that I would like the autoconfiscation to go into mainline of
gcc and of src at the same time.  I'm not sure what the best strategy to
try to achieve that is, given the different schedules and processes of
gcc, binutils, and gdb.

Should I start a branch?  I have various worries about doing that for
this particular project, which I may have stated elsewhere.

Advantages of the autoconfiscation:
----------------------------------
* Nearly all the 'make' logic is in dependencies, not embedded rules.
This makes 'make' faster, particularly on incremental builds.  It also
helps avoid certain types of bugs.
* Repetitive makefile targets are autogenerated, avoiding nasty typos
(do a grep on the old Makefile for 'check-mmcheckoc' to see what I
mean), and making changes significantly simpler.
* All subconfigures are invoked from the Makefile rather than
directly from top level configure.  This has certain debugging
advantages.
* ~55K less code to maintain manually.
* No more Cygnus configure.

Potential disadvantages:
------------------------
* To avoid a lot of subtle problems, configure uses absolute pathnames
for most directories which it puts into the Makefile.  This means you
can no longer 'configure', relocate srcdir or builddir, and then 'make'.
I doubt that this is important.
* I'm sure there's more I can do to clean it up.  I'd rather do that
after tackling some other cleanup projects though.

I'll try to submit the files involved sometime; they're kinda large.

--Nathanael