Top Level Autoconfiscation Status

Top Level Autoconfiscation Status

[Nathanael Nerode]

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

Re: Top Level Autoconfiscation Status

[Tim Hollebeek]

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

It could cause problems with mounted directories, which can have
different names on different machines.  E.g. if I do a "make" in
/usr/export/src/gcc and then try to do a "make install" in
/net/src/gcc on a different machine.

Re: Top Level Autoconfiscation Status

[Daniel Jacobowitz]

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

Re: Top Level Autoconfiscation Status

[Tom Tromey]

>>>>> "Nathanael" == Nathanael Nerode <neroden@doctormoo.dyndns.org> writes:

Nathanael> * zlib has no check target, so I have to somehow leave it
Nathanael> out

zlib definitely does have a check target in my tree:

    fleche. grep ^check: zlib/Makefile.in 
    check: check-am

Why doesn't it in yours?  Automake always generates a check target.
It would be a severe (and surprising) bug if it were missing.

Nathanael> * To avoid a lot of subtle problems, configure uses
Nathanael> absolute pathnames for most directories which it puts into
Nathanael> the Makefile.  This means you can no longer 'configure',
Nathanael> relocate srcdir or builddir, and then 'make'.  I doubt that
Nathanael> this is important.

In the past I've heard that people actually do this.

Tom

Re: Top Level Autoconfiscation Status

[Andrea 'Fyre Wyzard' Bocci]

At 21:41 30/06/2002 -0400, Nathanael Nerode wrote:
>...
>
>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 offer to test it on cygwin (1.3.11-3 on XP Pro), if it can help.
Just tell me whatever I can do :-)

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

fwyzard

Re: Top Level Autoconfiscation Status

[Ben Elliston]

>>>>> "Nathanael" == Nathanael Nerode <neroden@doctormoo.dyndns.org> writes:

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

As a suggestion: it is pointless to try and understand these failures
in the context of your configury changes.  You should take a tree
before your build, run the testsuite to obtain a baseline, apply your
changes and re-run the testsuite looking for regressions.

Ben

Re: Top Level Autoconfiscation Status

[Jeff Law]

In message <20020630221237.A2110@hollebeek.com>, Tim Hollebeek writes:
 >> * 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 do this regularly -- especially on machines where configure is slow
(hpux, aix, solaris).

 >It could cause problems with mounted directories, which can have
 >different names on different machines.  E.g. if I do a "make" in
 >/usr/export/src/gcc and then try to do a "make install" in
 >/net/src/gcc on a different machine.
Also a real problem.

jeff

Re: Top Level Autoconfiscation Status

[Andrew Cagney]

> In message <20020630221237.A2110@hollebeek.com>, Tim Hollebeek writes:
>  >> * 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 do this regularly -- especially on machines where configure is slow
> (hpux, aix, solaris).

I believe that both BFD and READLINE (in src) are currently broken in 
this regard (DJE reported problems).  There was a somewhat underwelming 
response (see binutils) when it was suggested that developers should be 
responsible for ensuring that this obscure functionality continues to work.

>  >It could cause problems with mounted directories, which can have
>  >different names on different machines.  E.g. if I do a "make" in
>  >/usr/export/src/gcc and then try to do a "make install" in
>  >/net/src/gcc on a different machine.
> Also a real problem.

Andrew

Re: Top Level Autoconfiscation Status

[Jeff Law]

In message <3D20818E.1040706@ges.redhat.com>, Andrew Cagney writes:
 >> In message <20020630221237.A2110@hollebeek.com>, Tim Hollebeek writes:
 >>  >> * 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 do this regularly -- especially on machines where configure is slow
 >> (hpux, aix, solaris).
 >
 >I believe that both BFD and READLINE (in src) are currently broken in 
 >this regard (DJE reported problems).  There was a somewhat underwelming 
 >response (see binutils) when it was suggested that developers should be 
 >responsible for ensuring that this obscure functionality continues to work.
Hmmm, I'm 99.9% sure I recently did this with a tree which included
BFD & READLINE and I didn't see any problems.  That doesn't mean such 
problems don't exist -- it merely means I didn't run into them.

jeff

Re: Top Level Autoconfiscation Status

[Andrew Cagney]

See:
http://sources.redhat.com/ml/gdb/2002-05/msg00330.html
http://sources.redhat.com/ml/binutils/2002-05/msg00702.html

> In message <3D20818E.1040706@ges.redhat.com>, Andrew Cagney writes:
>  >> In message <20020630221237.A2110@hollebeek.com>, Tim Hollebeek writes:
>  >>  >> * 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 do this regularly -- especially on machines where configure is slow
>  >> (hpux, aix, solaris).
>  >
>  >I believe that both BFD and READLINE (in src) are currently broken in 
>  >this regard (DJE reported problems).  There was a somewhat underwelming 
>  >response (see binutils) when it was suggested that developers should be 
>  >responsible for ensuring that this obscure functionality continues to work.
> Hmmm, I'm 99.9% sure I recently did this with a tree which included
> BFD & READLINE and I didn't see any problems.  That doesn't mean such 
> problems don't exist -- it merely means I didn't run into them.
> 
> jeff
> 
> 


Andrew

Re: Top Level Autoconfiscation Status

[Doug Evans]

Andrew Cagney writes:
 > >  >I believe that both BFD and READLINE (in src) are currently broken in 
 > >  >this regard (DJE reported problems).  There was a somewhat underwelming 
 > >  >response (see binutils) when it was suggested that developers should be 
 > >  >responsible for ensuring that this obscure functionality continues to work.

Obscure?!  Underwhelming?!

Has there been some email I missed?  [I was on vacation for awhile.]

I only found two problems.  The readline one seemed trivially
fixable.  Haven't put much thought into the other one
(top level configure specifying full path for --with-gcc-version-trigger
or some such, not bfd).

If this feature is removed (by the fact that bugs when found won't
be fixed) that'd be a great shame!