Re: Top Level Autoconfiscation Status

[Daniel Jacobowitz <drow@mvista.com>]

On Sun, Jun 30, 2002 at 09:41:39PM -0400, Nathanael Nerode wrote:
> 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

Most work cross if you have a simulator.  Above is just about the
standard test results for GDB; it's always a little messy.


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

That's the DBR timeout if I remember correctly; don't worry about it.

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

As long as it doesn't happen in the next week or so; binutils has a
branch coming up in early July.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer