Re: Trunk frustration

Re: Trunk frustration

[Richard Kenner]

    In hindsight, it might have been better to have used a branch...

My question about using a branch for this sort of work is how will it get
tested?  Doing it in the trunk has a risk for destabilization, but at least
it gets thoroughly tested by lots of people.  If you're making incremental
changes instead of installing a whole new pass, it can be very useful to
get the feedback that occurs from doing this on the trunk.

So I think a case like this is a close call as to where it can most
effectively be done.

Re: Trunk frustration

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     In hindsight, it might have been better to have used a branch...
> 
> My question about using a branch for this sort of work is how will it get
> tested?  Doing it in the trunk has a risk for destabilization, but at least
> it gets thoroughly tested by lots of people.  If you're making incremental
> changes instead of installing a whole new pass, it can be very useful to
> get the feedback that occurs from doing this on the trunk.
> 
> So I think a case like this is a close call as to where it can most
> effectively be done.

It's not fair to other contributors to simply commit your buggy
patches to the trunk and expect everyone else to clean up your mess.
It's just a way of forcing other people to do work that you couldn't
be bothered doing and that they'd rather not do either.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Trunk frustration

[Jan Hubicka]

> On Jul 30, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:
> 
> > On Fri, 27 Jul 2001, Jan Hubicka wrote:
> >> Do you use different configuration thatn sparc-sun-solaris2.8?
> >> Any chance that the bug got fixed?
> 
> > No, it still fails with the original symptoms
> 
> It still looks like the binary is being interpreted as a shell
> script.  Can you run it by hand?  What does `file' say about it?  How
> about readelf or objdump?
I would also guess this to be environment related problem. I am getting
sucessfull bootstraps on the same targets.  We are just trying to figure
out what is going wrong.

Honza
> 
> -- 
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Trunk frustration

[Alexandre Oliva]

On Jul 30, 2001, Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> wrote:

> On Fri, 27 Jul 2001, Jan Hubicka wrote:
>> Do you use different configuration thatn sparc-sun-solaris2.8?
>> Any chance that the bug got fixed?

> No, it still fails with the original symptoms

It still looks like the binary is being interpreted as a shell
script.  Can you run it by hand?  What does `file' say about it?  How
about readelf or objdump?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Trunk frustration

[Gerald Pfeifer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Fri, 27 Jul 2001, Jan Hubicka wrote:
> Do you use different configuration thatn sparc-sun-solaris2.8?
> Any chance that the bug got fixed?

No, it still fails with the original symptoms (after fixing bootstrap
with your non-yet-committed patch):

/files/pfeifer/OBJ-0730-1750/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits:
^A}^A~^A\202^A\203^A\205^A\206^A\207^A\211^A\214^A\216^A\217^A\220^A\221^A\223^A\225^A\226^A\230^A\231^A\232^A\233^A\234^A\235^A\237^A\240^A¢^A£^A¥^A¦^A§^A©^Aª^A¬^A­^A®^A°^A±^A²^A³^Aµ^A¶^A¸^A¹^Aº^A»^A¼^A¾^AÀ^AÁ^AÂ^AÃ^AÄ^AÅ^AÇ^AÈ^AÊ^AË^AÌ^AÎ^AÏ^AÐ^AÑ^AÓ^AÕ^A×^AØ^AÚ^AÛ^AÜ^AÝ^AÞ^Aß^Aà^Aá^Aã^Aä^Aå^Aæ^Aç^Aè^Aê^Aì^Aí^Aî^Aï^Að^Añ^Aó^Aô^Aö^A÷^Aø^Aú^Aû^Aü^Aþ^Aÿ^B^B^A^B^C^B^D^B^F^B^G^B^H^B:
not found
/files/pfeifer/OBJ-0730-1750/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits:
syntax error at line 4: `(' unexpected
/files/pfeifer/OBJ-0730-1750/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits:
syntax error at line 3: `(' unexpected

Gerald

Re: Trunk frustration

[Jan Hubicka]

> 
> I have been using Sun as and Sun ld for years without problems.
> 
> And in fact my last successful build dates back only four days, so I
> really hope we're just seeing some short term problem here.
> 
> Thanks for having a look at this issue!
I am getting increassingly puzzled.  Wasn't bootstrap expected to die here?
/tmp/egcs/build/gcc/xgcc -B/tmp/egcs/build/gcc/ -B/usr/local/sparc-sun-solaris2.8/bin/ -B/usr/local/sparc-sun-solaris2.8/lib/ -isystem /usr/local/sparc-sun-solaris2.8/include  -m64 -I/tmp/egcs/build/sparc-sun-solaris2.8/sparcv9/libstdc++-v3 -I./sparc-sun-solaris2.8/bits/.. -I/tmp/egcs/build/sparc-sun-solaris2.8/sparcv9/libstdc++-v3 -fno-exceptions     -o /tmp/egcs/build/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits /tmp/egcs/libstdc++-v3/src/gen-num-limits.cc
sed -e '/^#/s/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_][ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*\)/_GLIBCPP_\1/g' \
    -e 's,^#include "\(.*\)",#include <bits/\1>,g' \
    < /tmp/egcs/libstdc++-v3/../gcc/gthr.h > sparc-sun-solaris2.8/bits/gthr.h
sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCPP_\1/g' \
    < /tmp/egcs/libstdc++-v3/../gcc/gthr-single.h > sparc-sun-solaris2.8/bits/gthr-single.h
sed -e 's/\(UNUSED\)/_GLIBCPP_\1/g' \
    -e 's/\(GCC[ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*_H\)/_GLIBCPP_\1/g' \
    -e 's/\([ABCDEFGHIJKLMNOPQRSTUVWXYZ_]*WEAK\)/_GLIBCPP_\1/g' \
    < /tmp/egcs/libstdc++-v3/../gcc/gthr-posix.h > sparc-sun-solaris2.8/bits/gthr-default.h
make[7]: Leaving directory `/tmp/egcs/build/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/include'
Making all in libio
make[7]: Entering directory `/tmp/egcs/build/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/libio'
make[7]: Nothing to be done for `all'.
make[7]: Leaving directory `/tmp/egcs/build/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/libio'
Making all in libmath


Do you use different configuration thatn sparc-sun-solaris2.8?
Any chance that the bug got fixed?

Honza

Re: Trunk frustration

[Fergus Henderson]

On 27-Jul-2001, Jan Hubicka <jh@suse.cz> wrote:
> > 
> > Thanks for having a look at this issue!
> BTW I am getting much earlier build failure:
> ar rc libbackend.a alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o combine.o conflict.o convert.o cse.o cselib.o dbxout.o debug.o dependence.o df.o diagnostic.o doloop.o dominance.o dwarf2asm.o dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o global.o graph.o haifa-sched.o hash.o hashtable.o ifcvt.o insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o lcm.o lists.o local-alloc.o loop.o mbchar.o optabs.o params.o predict.o print-rtl.o print-tree.o profile.o real.o recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o sibcall.o simplify-rtx.o splay-tree.o ssa.o ssa-ccp.o ssa-dce.o stmt.o stor-layout.o stringpool.o timevar.o toplev.o tree.o unroll.o varasm.o varray.o version.o xcoffout.o gg!
 c-page.o sparc.o
> true libbackend.a
> gcc  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cc1 \
>         c-parse.o c-lang.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o
> c-semantics.o c-dump.o libcpp.a  main.o libbackend.a obstack.o      ../libiberty/libiberty.a
> gcc: main.o: No such file or directory
> 
> 
> OK, I will try to figure out where the makefiles got confused.

That one might be my fault; it was my change from a few months ago that
introduced main.o:

	2001-03-05  Fergus Henderson  <fjh@cs.mu.oz.au>

		Put main() in a separate file, so that the language
		front-end can use a different main().

		* main.c: New.
		* toplev.c: (main): Rename as toplev_main.
		* toplev.h: Declare toplev_main.
		* Makefile.in (OBJS): add toplev.o.
		  (BACKEND): remove toplev.o, add main.o.

Hmm, main.o isn't included in STAGESTUFF -- that looks like it might be a problem.
Does the following (as yet untested) patch help?

2001-07-28  Fergus Henderson  <fjh@cs.mu.oz.au>

	* Makefile.in (STAGESTUFF): add main.o.

Index: Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.690
diff -u -d -u -r1.690 Makefile.in
--- Makefile.in	2001/07/06 18:39:56	1.690
+++ Makefile.in	2001/07/27 14:44:47
@@ -776,7 +776,7 @@
  $(EXTRA_PARTS) $(EXTRA_PROGRAMS) gcc-cross$(exeext) cc1obj$(exeext) \
  enquire$(exeext) protoize$(exeext) unprotoize$(exeext) \
  specs collect2$(exeext) $(USE_COLLECT2) underscore.c tradcpp0$(exeext) \
- gcov$(exeext) *.[0-9][0-9].* *.[si] libcpp.a libbackend.a libgcc.mk \
+ gcov$(exeext) *.[0-9][0-9].* *.[si] libcpp.a main.o libbackend.a libgcc.mk \
  $(LANG_STAGESTUFF)
 
 # Library members defined in libgcc2.c.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: < http://www.cs.mu.oz.au/~fjh >  |     -- the last words of T. S. Garp.

Re: Trunk frustration

[Jan Hubicka]

> On 27-Jul-2001, Jan Hubicka <jh@suse.cz> wrote:
> > > 
> > > Thanks for having a look at this issue!
> > BTW I am getting much earlier build failure:
> > ar rc libbackend.a alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o combine.o conflict.o convert.o cse.o cselib.o dbxout.o debug.o dependence.o df.o diagnostic.o doloop.o dominance.o dwarf2asm.o dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o global.o graph.o haifa-sched.o hash.o hashtable.o ifcvt.o insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o lcm.o lists.o local-alloc.o loop.o mbchar.o optabs.o params.o predict.o print-rtl.o print-tree.o profile.o real.o recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o sibcall.o simplify-rtx.o splay-tree.o ssa.o ssa-ccp.o ssa-dce.o stmt.o stor-layout.o stringpool.o timevar.o toplev.o tree.o unroll.o varasm.o varray.o version.o xcoffout.o gg!
>  c-page.o sparc.o
> > true libbackend.a
> > gcc  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cc1 \
> >         c-parse.o c-lang.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o
> > c-semantics.o c-dump.o libcpp.a  main.o libbackend.a obstack.o      ../libiberty/libiberty.a
> > gcc: main.o: No such file or directory
> > 
> > 
> > OK, I will try to figure out where the makefiles got confused.
> 
> That one might be my fault; it was my change from a few months ago that
> introduced main.o:
Actually this seems to be false alarm caused by broken tree.
I've made fresh checkout and got pass the problematic point.

Honza

Re: Trunk frustration

[Jan Hubicka]

> On Fri, 27 Jul 2001, Jan Hubicka wrote:
> > We are having ultralinux installation here and at least there we got
> > crashes during bootstrap on gen_highpart and several other places.
> >
> > Do you bootstrap 32bit or 64bit compiler?
> 
> 32-bit, so I guess that's why it has been working for me (until four days
> ago).
Mee too.
It sound dificult to believe as the crash in question appeared in libgcc.a

I've tracked the Makefile problem to be due to broken cvs checkout, so at
least something is easy.

Honza

Re: Trunk frustration

[Gerald Pfeifer]

On Fri, 27 Jul 2001, Jan Hubicka wrote:
> We are having ultralinux installation here and at least there we got
> crashes during bootstrap on gen_highpart and several other places.
>
> Do you bootstrap 32bit or 64bit compiler?

32-bit, so I guess that's why it has been working for me (until four days
ago).

> BTW I am getting much earlier build failure:
> ar rc libbackend.a alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o combine.o conflict.o convert.o cse.o cselib.o dbxout.o debug.o dependence.o df.o diagnostic.o doloop.o dominance.o dwarf2asm.o dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o global.o graph.o haifa-sched.o hash.o hashtable.o ifcvt.o insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o lcm.o lists.o local-alloc.o loop.o mbchar.o optabs.o params.o predict.o print-rtl.o print-tree.o profile.o real.o recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o sibcall.o simplify-rtx.o splay-tree.o ssa.o ssa-ccp.o ssa-dce.o stmt.o stor-layout.o stringpool.o timevar.o toplev.o tree.o unroll.o varasm.o varray.o version.o xcoffout.o gg!
c-page.o sparc.o
> true libbackend.a
> gcc  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cc1 \
>         c-parse.o c-lang.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o
> c-semantics.o c-dump.o libcpp.a  main.o libbackend.a obstack.o      ../libiberty/libiberty.a
> gcc: main.o: No such file or directory
>
>
> OK, I will try to figure out where the makefiles got confused.

Thanks!

This is the real problem: We're having so many different problems this
week, that it's very hard to attack any single one.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Trunk frustration

[Jan Hubicka]

> 
> Thanks for having a look at this issue!
BTW I am getting much earlier build failure:
ar rc libbackend.a alias.o bb-reorder.o bitmap.o builtins.o caller-save.o calls.o combine.o conflict.o convert.o cse.o cselib.o dbxout.o debug.o dependence.o df.o diagnostic.o doloop.o dominance.o dwarf2asm.o dwarf2out.o dwarfout.o emit-rtl.o except.o explow.o expmed.o expr.o final.o flow.o fold-const.o function.o gcse.o genrtl.o ggc-common.o global.o graph.o haifa-sched.o hash.o hashtable.o ifcvt.o insn-attrtab.o insn-emit.o insn-extract.o insn-opinit.o insn-output.o insn-peep.o insn-recog.o integrate.o intl.o jump.o lcm.o lists.o local-alloc.o loop.o mbchar.o optabs.o params.o predict.o print-rtl.o print-tree.o profile.o real.o recog.o reg-stack.o regclass.o regmove.o regrename.o reload.o reload1.o reorg.o resource.o rtl.o rtlanal.o sbitmap.o sched-deps.o sched-ebb.o sched-rgn.o sched-vis.o sdbout.o sibcall.o simplify-rtx.o splay-tree.o ssa.o ssa-ccp.o ssa-dce.o stmt.o stor-layout.o stringpool.o timevar.o toplev.o tree.o unroll.o varasm.o varray.o version.o xcoffout.o ggc-page.o sparc.o
true libbackend.a
gcc  -DIN_GCC    -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wtraditional -pedantic -Wno-long-long  -DHAVE_CONFIG_H  -o cc1 \
        c-parse.o c-lang.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-format.o
c-semantics.o c-dump.o libcpp.a  main.o libbackend.a obstack.o      ../libiberty/libiberty.a
gcc: main.o: No such file or directory


OK, I will try to figure out where the makefiles got confused.

Honza

Re: Trunk frustration

[Jan Hubicka]

> On Fri, 27 Jul 2001, Jan Hubicka wrote:
> > I've got an access to ultrasparc/solaris box able to build gcc, so I will
> > try to figure out whats going out.
> 
> Thanks!
> 
> > Note that the sparc backend has been broken for few months before I
> > started work on the cfg_cleanup.
> 
> Really? I have been bootstrapping GCC several times a week and compiled
> our heave C++ projects without problems (apart from long compile times and
> bad code generation compared to GCC 2.95, but that's not a SPARC-specific
> issue).
This is really interesting.
We are having ultralinux installation here and at least there we got crashes
during bootstrap on gen_highpart and several other places.

Do you bootstrap 32bit or 64bit compiler?
> 
> > I made it working for the testing (I wanted to have few architectures
> > available), but I never really tested the unmodified numeric_limits in
> > C++, as the box had outdated binutils not being able to cope with C++
> > w/o some hackery.
> 
> I have been using Sun as and Sun ld for years without problems.
> 
> And in fact my last successful build dates back only four days, so I
> really hope we're just seeing some short term problem here.
> 
> Thanks for having a look at this issue!
Hope I will have luck to localize problem. C++ is not my strong point.

Honza
> 
> Gerald
> -- 
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Trunk frustration

[Gerald Pfeifer]

On Fri, 27 Jul 2001, Jan Hubicka wrote:
> I've got an access to ultrasparc/solaris box able to build gcc, so I will
> try to figure out whats going out.

Thanks!

> Note that the sparc backend has been broken for few months before I
> started work on the cfg_cleanup.

Really? I have been bootstrapping GCC several times a week and compiled
our heave C++ projects without problems (apart from long compile times and
bad code generation compared to GCC 2.95, but that's not a SPARC-specific
issue).

> I made it working for the testing (I wanted to have few architectures
> available), but I never really tested the unmodified numeric_limits in
> C++, as the box had outdated binutils not being able to cope with C++
> w/o some hackery.

I have been using Sun as and Sun ld for years without problems.

And in fact my last successful build dates back only four days, so I
really hope we're just seeing some short term problem here.

Thanks for having a look at this issue!

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Trunk frustration

[Jan Hubicka]

> On 26 Jul 2001, Gabriel Dos Reis wrote:
> > Hmm, may that be related to this patch
> >
> >    2001-07-19  Gabriel Dos Reis  <gdr@merlin.codesourcery.com>
> > 	       Bert De Knuydt <Bert.Deknuydt@esat.kuleuven.ac.be>
> >
> > 	   * src/gen-num-limits.cc (set_signals_handler): New function.
> > 	   Factor out signals setting.  Set signal handler for SIGILL.
> >
> > I cheked in that patch precisely because, there were an "illegation
> > instruction" trap at startup.  Several people which tested the patch
> > reported the problem was fixed.
> 
> I tried with that patch reverted, and basically keep getting the same
> build failure.
I've got an access to ultrasparc/solaris box able to build gcc, so I will
try to figure out whats going out.

Note that the sparc backend has been broken for few months before I started
work on the cfg_cleanup.  I made it working for the testing (I wanted to have
few architectures available), but I never really tested the unmodified
numeric_limits in C++, as the box had outdated binutils not being able to cope
with C++ w/o some hackery.

Honza
> 
> Gerald
> -- 
> Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Trunk frustration

[Toon Moene]

Tim Josling wrote:

> As I understand it one of the issues is that Jan does not have an i86
> machine to test his patches on. If soneone could find him such a
> machine, I suspect we would all be a lot better off!

Hmmm, my impression is that Jan *only* has a ix86 machine to his
disposal.

[ Searching inbox .... ]

"Bootstrapped/regtested i686; requires the barriers patch to survive."

Bingo !

I sincerely think the best thing to do is to develop such far-reaching
changes on a branch and ask people for help when you think you're
finished, like Jan is now proposing.

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Trunk frustration

[Gabriel Dos Reis]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

| On 26 Jul 2001, Gabriel Dos Reis wrote:
| > Hmm, may that be related to this patch
| >
| >    2001-07-19  Gabriel Dos Reis  <gdr@merlin.codesourcery.com>
| > 	       Bert De Knuydt <Bert.Deknuydt@esat.kuleuven.ac.be>
| >
| > 	   * src/gen-num-limits.cc (set_signals_handler): New function.
| > 	   Factor out signals setting.  Set signal handler for SIGILL.
| >
| > I cheked in that patch precisely because, there were an "illegation
| > instruction" trap at startup.  Several people which tested the patch
| > reported the problem was fixed.
| 
| I tried with that patch reverted, and basically keep getting the same
| build failure.

Ah, so for one thing it isn't a recent change to src/gen-num-limits.C.
Then the problem is elsewhere.  That doesn't solve your problem (I
wish I knew what is the root) but it makes us keep a critical patch in.

I'm sorry for having pointed you into a wrong direction.

-- Gaby
CodeSourcery, LLC                       http://www.codesourcery.com

Re: Trunk frustration

[Gerald Pfeifer]

On 26 Jul 2001, Gabriel Dos Reis wrote:
> Hmm, may that be related to this patch
>
>    2001-07-19  Gabriel Dos Reis  <gdr@merlin.codesourcery.com>
> 	       Bert De Knuydt <Bert.Deknuydt@esat.kuleuven.ac.be>
>
> 	   * src/gen-num-limits.cc (set_signals_handler): New function.
> 	   Factor out signals setting.  Set signal handler for SIGILL.
>
> I cheked in that patch precisely because, there were an "illegation
> instruction" trap at startup.  Several people which tested the patch
> reported the problem was fixed.

I tried with that patch reverted, and basically keep getting the same
build failure.

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Trunk frustration

[Gerald Pfeifer]

On Thu, 26 Jul 2001, Jan Hubicka wrote:
> I was havine equivaelnt failures when buldining in-tree.

Just to make sure: I'm building with srcdir != objdir (and actually
even mounted from a different host and filesystem).

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Trunk frustration

[Tim Josling]

As I understand it one of the issues is that Jan does not have an i86
machine to test his patches on. If soneone could find him such a
machine, I suspect we would all be a lot better off!

Tim Josling

If there is a technical solution to a problem, it is the best solution.

Re: Trunk frustration

[Jan Hubicka]

> 
> Is it not marked executable, or just not producing a valid executable
> at all?
I was havine equivaelnt failures when buldining in-tree.
Out of tree I now buld sucesfully on ultralinxes.

Honza

Re: Trunk frustration

[Gabriel Dos Reis]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

| > Is it not marked executable, or just not producing a valid executable
| > at all?
| 
| It is marked executable, but crashes upon startup.

Hmm, may that be related to this patch

   2001-07-19  Gabriel Dos Reis  <gdr@merlin.codesourcery.com>
	       Bert De Knuydt <Bert.Deknuydt@esat.kuleuven.ac.be>

	   * src/gen-num-limits.cc (set_signals_handler): New function.
	   Factor out signals setting.  Set signal handler for SIGILL.

I cheked in that patch precisely because, there were an "illegation
instruction" trap at startup.  Several people which tested the patch
reported the problem was fixed.

-- Gaby

Re: Trunk frustration

[Gerald Pfeifer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2134 bytes --]

On Thu, 26 Jul 2001, Daniel Berlin wrote:
>> mv /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/include/bits/std_limits.h ./sparc-sun-solaris2.8/bits
>> running mknumeric_limits
>> /files/pfeifer/OBJ-0726-0812/gcc/xgcc -B/files/pfeifer/OBJ-0726-0812/gcc/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/bin/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/lib/ -isystem /sw/test/gcc/SunOS/sparc-sun-solaris2.8/include  -m64 -I/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3 -I./sparc-sun-solaris2.8/bits/.. -I/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3 -fno-exceptions     -o /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits /sw/test/gcc/cvs/libstdc++-v3/src/gen-num-limits.cc
>> /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits: syntax error at line 3: `(' unexpected
>> /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits: ^A}^A~^A\202^A\203^A\205^A\206^A\207^A\211^A\214^A\216^A\217^A\220^A\221^A\223^A\225^A\226^A\230^A\231^A\232^A\233^A\234^A\235^A\237^A\240^A¢^A£^A¥^A¦^A§^A©^Aª^A¬^A­^A®^A°^A±^A²^A³^Aµ^A¶^A¸^A¹^Aº^A»^A¼^A¾^AÀ^AÁ^AÂ^AÃ^AÄ^AÅ^AÇ^AÈ^AÊ^AË^AÌ^AÎ^AÏ^AÐ^AÑ^AÓ^AÕ^A×^AØ^AÚ^AÛ^AÜ^AÝ^AÞ^Aß^Aà^Aá^Aã^Aä^Aå^Aæ^Aç^Aè^Aê^Aì^Aí^Aî^Aï^Að^Añ^Aó^Aô^Aö^A÷^Aø^Aú^Aû^Aü^Aþ^A^?^B^B^A^B^C^B^D^B^F^B^G^B^H^B: not found
>> /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits: syntax error at line 4: `(' unexpected
>> gen-num-limits failed to execute, exiting.
> Is it not marked executable, or just not producing a valid executable
> at all?

It is marked executable, but crashes upon startup.

(I can reproduce this deterministically, that is, I've been getting this
for three different builds on this box.)

Gerald
-- 
Gerald "Jerry" pfeifer@dbai.tuwien.ac.at http://www.dbai.tuwien.ac.at/~pfeifer/

Re: Trunk frustration

[Daniel Berlin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3566 bytes --]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> On Thu, 26 Jul 2001, Andreas Jaeger wrote:
>> Glad to hear.  Do others still have problems (beside the RS6000
>> problems due to the debug changes) - or is the trunk fine again?
> 
> The trunk is still broken, albeit in a different way, on
> sparc-sun-solaris2.8 (for a non parallel make):

> 
> mv /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/include/bits/std_limits.h ./sparc-sun-solaris2.8/bits
> running mknumeric_limits
> /files/pfeifer/OBJ-0726-0812/gcc/xgcc -B/files/pfeifer/OBJ-0726-0812/gcc/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/bin/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/lib/ -isystem /sw/test/gcc/SunOS/sparc-sun-solaris2.8/include  -m64 -I/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3 -I./sparc-sun-solaris2.8/bits/.. -I/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3 -fno-exceptions     -o /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits /sw/test/gcc/cvs/libstdc++-v3/src/gen-num-limits.cc
> /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits: syntax error at line 3: `(' unexpected
> /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits: ^A}^A~^A\202^A\203^A\205^A\206^A\207^A\211^A\214^A\216^A\217^A\220^A\221^A\223^A\225^A\226^A\230^A\231^A\232^A\233^A\234^A\235^A\237^A\240^A¢^A£^A¥^A¦^A§^A©^Aª^A¬^A­^A®^A°^A±^A²^A³^Aµ^A¶^A¸^A¹^Aº^A»^A¼^A¾^AÀ^AÁ^AÂ^AÃ^AÄ^AÅ^AÇ^AÈ^AÊ^AË^AÌ^AÎ^AÏ^AÐ^AÑ^AÓ^AÕ^A×^AØ^AÚ^AÛ^AÜ^AÝ^AÞ^Aß^Aà^Aá^Aã^Aä^Aå^Aæ^Aç^Aè^Aê^Aì^Aí^Aî^Aï^Að^Añ^Aó^Aô^Aö^A÷^Aø^Aú^Aû^Aü^Aþ^A^?^B^B^A^B^C^B^D^B^F^B^G^B^H^B: not found
> /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits: syntax error at line 4: `(' unexpected
> gen-num-limits failed to execute, exiting.
> mv: cannot access /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/include/bits/std_limits.h
> gmake[8]: *** [sparc-sun-solaris2.8/bits/std_limits.h] Error 2
> gmake[8]: Leaving directory `/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/include'
> gmake[7]: *** [all-recursive] Error 1
> gmake[7]: Leaving directory `/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3'
> [...]
> gmake[1]: *** [all-target-libstdc++-v3] Error 2
> gmake[1]: Leaving directory `/files/pfeifer/OBJ-0726-0812'
> 
> 

Is it not marked executable, or just not producing a valid executable
at all?

> This exactly *is* the problem I've been complaining about: Three different
> failure modes within two days, one on top of the other, so it is getting
> increasingly difficult to debug. :-(
> 
> Gerald

-- 
"A while ago, I went skiing in England.  It was a rare package:
two weeks in England, one night in Connecticut, two weeks in
England.  I said, "Yes, I'll take it."  I got on this chairlift
with this guy I didn't know.  We went halfway up the mountain
without saying a word.  Then he turned to me and said, "You
know, this is the first time I've gone skiing in ten years."  I
said, "Why did you take such a long time off?"  He said, "I was
in prison.  Want to know why?"  I said, "Not really.  Well, you
better tell me why."  He said, "I pushed a total stranger off a
Ferris wheel."  I said, "I remember you."
"-Steven Wright

Re: Trunk frustration

[Gerald Pfeifer]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2747 bytes --]

On Thu, 26 Jul 2001, Andreas Jaeger wrote:
> Glad to hear.  Do others still have problems (beside the RS6000
> problems due to the debug changes) - or is the trunk fine again?

The trunk is still broken, albeit in a different way, on
sparc-sun-solaris2.8 (for a non parallel make):

mv /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/include/bits/std_limits.h ./sparc-sun-solaris2.8/bits
running mknumeric_limits
/files/pfeifer/OBJ-0726-0812/gcc/xgcc -B/files/pfeifer/OBJ-0726-0812/gcc/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/bin/ -B/sw/test/gcc/SunOS/sparc-sun-solaris2.8/lib/ -isystem /sw/test/gcc/SunOS/sparc-sun-solaris2.8/include  -m64 -I/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3 -I./sparc-sun-solaris2.8/bits/.. -I/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3 -fno-exceptions     -o /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits /sw/test/gcc/cvs/libstdc++-v3/src/gen-num-limits.cc
/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits: syntax error at line 3: `(' unexpected
/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits: ^A}^A~^A\202^A\203^A\205^A\206^A\207^A\211^A\214^A\216^A\217^A\220^A\221^A\223^A\225^A\226^A\230^A\231^A\232^A\233^A\234^A\235^A\237^A\240^A¢^A£^A¥^A¦^A§^A©^Aª^A¬^A­^A®^A°^A±^A²^A³^Aµ^A¶^A¸^A¹^Aº^A»^A¼^A¾^AÀ^AÁ^AÂ^AÃ^AÄ^AÅ^AÇ^AÈ^AÊ^AË^AÌ^AÎ^AÏ^AÐ^AÑ^AÓ^AÕ^A×^AØ^AÚ^AÛ^AÜ^AÝ^AÞ^Aß^Aà^Aá^Aã^Aä^Aå^Aæ^Aç^Aè^Aê^Aì^Aí^Aî^Aï^Að^Añ^Aó^Aô^Aö^A÷^Aø^Aú^Aû^Aü^Aþ^A^?^B^B^A^B^C^B^D^B^F^B^G^B^H^B: not found
/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/gen-num-limits: syntax error at line 4: `(' unexpected
gen-num-limits failed to execute, exiting.
mv: cannot access /files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/include/bits/std_limits.h
gmake[8]: *** [sparc-sun-solaris2.8/bits/std_limits.h] Error 2
gmake[8]: Leaving directory `/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/include'
gmake[7]: *** [all-recursive] Error 1
gmake[7]: Leaving directory `/files/pfeifer/OBJ-0726-0812/sparc-sun-solaris2.8/sparcv9/libstdc++-v3'
[...]
gmake[1]: *** [all-target-libstdc++-v3] Error 2
gmake[1]: Leaving directory `/files/pfeifer/OBJ-0726-0812'


This exactly *is* the problem I've been complaining about: Three different
failure modes within two days, one on top of the other, so it is getting
increasingly difficult to debug. :-(

Gerald

Re: Trunk frustration

[Andreas Jaeger]

Stan Shebs <shebs@apple.com> writes:

> Jan Hubicka wrote:
>> 
>> I feel really frustrated by the amount of problems I've caused and
>> didn't sleep much this week.
> 
> I do appreciate your efforts to get things back to working; I've

So do I - as soon as I reported to Honza a failure on Spec2000, I got
a "Working on it" back ;-).
> been able to bootstrap on Darwin since last night.

Glad to hear.  Do others still have problems (beside the RS6000
problems due to the debug changes) - or is the trunk fine again?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Trunk frustration

[Stan Shebs]

Jan Hubicka wrote:
> 
> I feel really frustrated by the amount of problems I've caused and
> didn't sleep much this week.

I do appreciate your efforts to get things back to working; I've
been able to bootstrap on Darwin since last night.

Stan

Re: Trunk frustration

[Jan Hubicka]

> trying to replace jump.c with a CFG equivalent and keep the CFG consistent
> throughout compilation.
> 
> The changes are quite extensive and have been consistently breaking the
> tree across a number of architectures.
> 
> While Jan tried to do this work incrementally it hasn't been that successful
> IMHO.
Gentlemens,
I really apologize for any frustration I've caused.
Originally I've consedered creating public branch for this work, but my
decision has been driven by following:
1) I need to change many parts of compiler, that means it will be dificult
   to maitain branch and avoid duplication of effort on mainline
2) I've created plan to do changes incrementaly, where each change is small
   and can be tested separately
3) I've implemented major body (up to killing jump pass) and tested concept
   as a whole, then break again to the incremental changes, so I've expected
   my way to be equally safe to the branch, just w/o doing it officially.
   (I've scheduled the work for 14 days I was mostly offline)
4) There has been number of design decisions and I wanted to see reviews
   before I get too far wrong way.

I've hoped this scheme to be safe and better than the branching.  I've
obviously underestimated the need to test multiple architectures
(again I've tested the "wholepatch" at sparc/mips/ppc/i686) and the
effect I get to other optimizations - number of bugs has been de-facto
latent problems everywhere, that didn't show because old jump didn't
the optimizations.

I feel really frustrated by the amount of problems I've caused and
didn't seleep much this week. Some of them were caused by my
ignorance about issues on reorg pass and others by cleanups I've made
after thesting the "wholepatch" and bootstrapped only on i686.

For this purpose I've decided to move my future work to the branch.  The major
failure I've made was definitly my lack of ability to recognize "problematic"
patches, that needs testing on multiple platforms and "simple" patches.  I've
gave lots of testing to patches I was affraid of, but dodn't payed enought
attention to the "simple" ones.  So I am going to test each on all platofrms I
have access to.

Unlike situation when I've started, now I don't need so much changes
to each pass (I hope) and I want to proceed by short-lived goals,
each time I reach goal, test major platforms, prepare patches,
test again and send for review.

So I hope I've learned something from the lesson and would be able
to do the rest without more major breakage.

The goals I consider for CFG are for instance:
1) Finishing the jump threading pass
2) Converting rest of passes except loop to CFG
3) Implementing better infrastructure to manipulate with CFG, mailny
   to do basic block duplication easilly.
4) Implement tracer and BB duplication pass using that infrastructure
3) Converting loop to CFG (I would like to discuss this with Michael
   Hayes, as I believe he did most of work needed for this goal)
4) Killing the leftout of jump infrastructure - LABEL_NUSES, barriers,
   jump tables lurking in insn stream etc. should go
5) ....

So please send me your comments and ideas.

Thank you for your understanding,
Honza

Re: Trunk frustration

[Geoff Keating]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

>     It's not fair to other contributors to simply commit your buggy
>     patches to the trunk and expect everyone else to clean up your mess.
>     It's just a way of forcing other people to do work that you couldn't
>     be bothered doing and that they'd rather not do either.
> 
> Obviously in the case of major development, that's right.  But I don't
> see the case we were talking about as being that major.  There are quite
> a lot of resources out there for testing and I do indeed feel that it's
> reasonable to distribute some of the testing load to the community at large.

I don't see that the size of the change necessarily has anything to do
with it.  Larger changes don't necessarily need more testing; the
testing requirement is determined by the need to ensure that the
change works.  A new port is "major development", but it needs only
minimal testing; yet a small change somewhere in the middle-end might
need to be tested on three or four targets if that's necessary to test
all the cases.

I agree that the community can supply lots of resources for testing.
However, it doesn't follow that it's OK to just appropriate community
resources for testing; the proper approach is to ask first.  One way
to do this is to place the changes on a branch and test them there
using "community resources"; another way is to post a patch and ask
individuals to test it.

> Jan's patches were incremental changes and I see a value in having
> available the resources of the community at large in the testing,
> especially where there aren't any problems expected.  That's the
> advantage of the incremental approach: you can take small steps, each
> of which you are quite confident of, and you'll find out if you were
> wrong.

I don't disagree with this approach.  It's just that I want people to
be confident because their patches have been tested carefully, not
confident because "it worked for me".

> Of course, this approach isn't reasonable, as you say, in the case a
> major development that isn't suited for the incremental approach.
> But if you can't use it in doing incremental changes, you lose much
> of the advantages of doing things incrementally and having a large
> development community.
> 
> I don't agree with the characterization of his patches as "buggy": yes, there
> was one (or perhaps two) with problems on some architectures, but the vast
> majority of them produced no problems at all.

I wasn't intending to refer to any particular individual in the above,
I was stating a general principle.

However, in the specific case, by my count there were eight patches so
far this month which caused regressions on either powerpc or i386, out
of 31 commits.

If only 10% of the 285 patches committed to gcc mainline so far this
month were broken enough to cause a regression, we would have
introduced 28 new regressions---more than one per day!  Because of the
high change rate of GCC we can't afford to have people commit patches
which they think are 'probably correct', or even '75% correct'.  We
need to aim for something on the order of 95% or 98%.

-- 
- Geoffrey Keating <geoffk@geoffk.org>

Re: Trunk frustration

[law]

  In message < 10107251453.AA05381@vlsi1.ultra.nyu.edu >you write:
  > Jan's patches were incremental changes and I see a value in having
  > available the resources of the community at large in the testing,
  > especially where there aren't any problems expected.  That's the
  > advantage of the incremental approach: you can take small steps, each
  > of which you are quite confident of, and you'll find out if you were
  > wrong.
I definitely consider Jan's changes major development -- he's basically
trying to replace jump.c with a CFG equivalent and keep the CFG consistent
throughout compilation.

The changes are quite extensive and have been consistently breaking the
tree across a number of architectures.

While Jan tried to do this work incrementally it hasn't been that successful
IMHO.

jeff

ps.  Note that I do applaud Jan's goal and effort.  Replacing jump.c with
its CFG equivalent and keeping the CFG up-to-date has been on my todo list
for a while now.

Re: Trunk frustration

[Richard Kenner]

    It's not fair to other contributors to simply commit your buggy
    patches to the trunk and expect everyone else to clean up your mess.
    It's just a way of forcing other people to do work that you couldn't
    be bothered doing and that they'd rather not do either.

Obviously in the case of major development, that's right.  But I don't
see the case we were talking about as being that major.  There are quite
a lot of resources out there for testing and I do indeed feel that it's
reasonable to distribute some of the testing load to the community at large.

Jan's patches were incremental changes and I see a value in having
available the resources of the community at large in the testing,
especially where there aren't any problems expected.  That's the
advantage of the incremental approach: you can take small steps, each
of which you are quite confident of, and you'll find out if you were
wrong.

Of course, this approach isn't reasonable, as you say, in the case a major
development that isn't suited for the incremental approach.  But if you can't
use it in doing incremental changes, you lose much of the advantages of doing
things incrementally and having a large development community.

I don't agree with the characterization of his patches as "buggy": yes, there
was one (or perhaps two) with problems on some architectures, but the vast
majority of them produced no problems at all.

Re: Trunk frustration

[Andreas Jaeger]

Mark Mitchell <mark@codesourcery.com> writes:

[...]
> And the answer is that, yes, this work probably should have been done
> on a branch.  It's goal seems to be to replace jump.c, which is great,
> but seems to me roughly equivalent to creating a brand-new optimization
> pass.

Honza started his work on the branch passes and was in the middle of
it before the policy about cvs branches was in effect.  We've
discussed privatly already this change in policy and agreed to finish
the current patches (two pending patches) and then the major work
should be done.

I hindsight, it might have been better to have used a branch...

For further changes (using the branch prediction information) I expect
that Honza will consider using a branch even if the branch might be
short-lived.  I've already discussed with him that I'll test the
result of his patches before integration on the mainline on machines
that I can access here locally (powerpc, athlon, sparc, ia64).

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

Re: Trunk frustration

[Mark Mitchell]

--On Monday, July 23, 2001 03:54:59 PM -0700 Stan Shebs <shebs@apple.com> 
wrote:

> Am I the only one who's frustrated with the current state of the
> trunk?

I'm sure I would be too if I were working on the trunk right now.

The answer is that we now have a policy that gives us a mechanism for
returning to a known good state in a short period of time.  However,
there are some checks and balances.  So, you need to identify the
first patch that caused a regression that is still not fixed, notify
the instigator of that patch, and then get two people with write
privileges to agree to revert the patch if the problem is not fixed
within 48 hours.

If you can identify multiple problem-causing patches, you can do them
all at once!

And the answer is that, yes, this work probably should have been done
on a branch.  It's goal seems to be to replace jump.c, which is great,
but seems to me roughly equivalent to creating a brand-new optimization
pass.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: Trunk frustration

[David Edelsohn]

	If we can pinpoint the patches which started the problems, we can
approach the contributor to fix the problem.  If the problem is not fixed,
we can revert the entire chain of patches from the mainline.

David

Re: Trunk frustration

[Neil Booth]

Sounds like some kind of elephant affliction :-)

Neil.

Trunk frustration

[Stan Shebs]

Am I the only one who's frustrated with the current state of the
trunk?  I've been trying to work up some of my own patches, but I
can't even test that the compiler still bootstraps with them, because
it doesn't bootstrap in the first place, or even completely build
most of the time.  It's been like this for over a week, seemingly
since the flow.c tinkering started, and in order to get my work done,
I have to do it all in Apple's version instead and hope to submit it
at some future date.

Sure, it's amusing and educational to single-step through flow
routines, but by the time I've figured out how it works today, it's
changed again.  Perhaps this should all be happening on a branch?
From the discussion I see on gcc-patches, it doesn't sound like
there is a consensus on how to do things, and the trunk is surely
not the right place for this kind of experimentation.

Stan