Readiness of tree-ssa

Readiness of tree-ssa

[Wolfgang Bangerth]

Just as another datapoint: we've got a number of people routinely compiling 
and running applications nightly. Off the top of my head, this would be 
Gerald, Guenther (POOMA), and me, and I'm certainly missing more. As far as I 
can see none of us has had much success with tree-ssa yet. 

I, for one, have repeatedly been stuck with ICEs and have never been able to 
compile my library completely. Neither have my PRs been fixed overly quickly 
(not that I would be entitled to this, it's just a request since I can't test 
with a compiler that's continually broken; my latest report is PR 13681). I 
can't say anything about speed or correctness of the generated code, of 
course.

I understand and appreciate that the tree-ssa people are putting a significant 
amount of work into the branch. However, I'd like to propose postponing the 
merge until at least the testers inside the gcc project are reasonably happy 
with the branch. Whatever they will find, we'll get as reports later anyway, 
but this way we could make sure that it's fixed before it propagates to the 
mainline.

W.
 
-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Readiness of tree-ssa

[Richard Guenther]

On Tue, 20 Jan 2004, Wolfgang Bangerth wrote:

> Just as another datapoint: we've got a number of people routinely compiling
> and running applications nightly. Off the top of my head, this would be
> Gerald, Guenther (POOMA), and me, and I'm certainly missing more. As far as I
> can see none of us has had much success with tree-ssa yet.
>
> I, for one, have repeatedly been stuck with ICEs and have never been able to
> compile my library completely. Neither have my PRs been fixed overly quickly
> (not that I would be entitled to this, it's just a request since I can't test
> with a compiler that's continually broken; my latest report is PR 13681). I
> can't say anything about speed or correctness of the generated code, of
> course.

Today for the first time I was able to compile my complete POOMA based
application with tree-ssa (on a machine with a reasonable amount of memory
- 1GB was not enough until recently).  If this were my first try, I'd say
"go ahead and merge" - because the remaining compile and runtime
regressions are likely to be addressed.  But of course with the mixed
experience I made in the past I'm inclined to hold off the merge for some
more time.

Oh, and of course, f.i. ia64 doesn't bootstrap on the branch for quite
some time now.

Keep it going!

Richard.

Re: Readiness of tree-ssa

[Diego Novillo]

On Tue, 2004-01-20 at 14:59, Richard Guenther wrote:

> Oh, and of course, f.i. ia64 doesn't bootstrap on the branch for quite
> some time now.
> 
It does now.


Diego.

Re: Readiness of tree-ssa

[Richard Guenther]

On Tue, 20 Jan 2004, Diego Novillo wrote:

> On Tue, 2004-01-20 at 14:59, Richard Guenther wrote:
>
> > Oh, and of course, f.i. ia64 doesn't bootstrap on the branch for quite
> > some time now.
> >
> It does now.

No it doesn't (updated 4 hours ago):

/bin/sh ../libtool --tag=CXX --mode=link
`/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags
--build-cxx` -R `/tmp/gcc-obj/gcc/xgcc -B/tmp/gcc-obj/gcc/
-B/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/bin/
-B/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/lib/ -isystem
/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/include -isystem
/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/sys-include
-print-libgcc-file-name | sed 's,/[^/]*$,,'` -R
/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs  -g -O2
-D_GNU_SOURCE  -o abi_check  abi_check.o  -lm
mkdir .libs
/tmp/gcc-obj/gcc/g++ -shared-libgcc -B/tmp/gcc-obj/gcc/ -nostdinc++
-B/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/bin/
-B/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/lib/ -isystem
/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/include -isystem
/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/sys-include -g -O2
-D_GNU_SOURCE -o abi_check abi_check.o
-L/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src
-L/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -lm
-Wl,--rpath -Wl,/tmp/gcc-obj/gcc -Wl,--rpath
-Wl,/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs
/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so:
undefined reference to `_Unwind_Resume_or_Rethrow'
collect2: ld returned 1 exit status
make[4]: *** [abi_check] Error 1
make[4]: Leaving directory
`/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/testsuite'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/tmp/gcc-obj'
make: *** [bootstrap] Error 2

see PR13766.

Richard.

Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)

[Richard Guenther]

I just checked 3.4 branch and get exactly the same failure.  And I can't
find any trace of _Unwind_Resume_or_Rethrow being defined or used anywhere
but as extern declaration in unwind.h and

unwind-sjlj.c:#define _Unwind_Resume_or_Rethrow	_Unwind_SjLj_Resume_or_Rethrow

anyone has an idea what I'm doing wrong? This is Debian unstable, binutils
is 2.14.90.0.7-3, libc 2.3.2.ds1-10.0.

Thanks,

Richard.

On Tue, 20 Jan 2004, Richard Guenther wrote:

> On Tue, 20 Jan 2004, Diego Novillo wrote:
>
> > On Tue, 2004-01-20 at 14:59, Richard Guenther wrote:
> >
> > > Oh, and of course, f.i. ia64 doesn't bootstrap on the branch for quite
> > > some time now.
> > >
> > It does now.
>
> No it doesn't (updated 4 hours ago):
>
> /bin/sh ../libtool --tag=CXX --mode=link
> `/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags
> --build-cxx` -R `/tmp/gcc-obj/gcc/xgcc -B/tmp/gcc-obj/gcc/
> -B/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/bin/
> -B/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/lib/ -isystem
> /home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/include -isystem
> /home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/sys-include
> -print-libgcc-file-name | sed 's,/[^/]*$,,'` -R
> /tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs  -g -O2
> -D_GNU_SOURCE  -o abi_check  abi_check.o  -lm
> mkdir .libs
> /tmp/gcc-obj/gcc/g++ -shared-libgcc -B/tmp/gcc-obj/gcc/ -nostdinc++
> -B/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/bin/
> -B/home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/lib/ -isystem
> /home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/include -isystem
> /home/rguenth/ia64/gccssa-200104/ia64-unknown-linux-gnu/sys-include -g -O2
> -D_GNU_SOURCE -o abi_check abi_check.o
> -L/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src
> -L/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs -lm
> -Wl,--rpath -Wl,/tmp/gcc-obj/gcc -Wl,--rpath
> -Wl,/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs
> /tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so:
> undefined reference to `_Unwind_Resume_or_Rethrow'
> collect2: ld returned 1 exit status
> make[4]: *** [abi_check] Error 1
> make[4]: Leaving directory
> `/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3/testsuite'
> make[3]: *** [all-recursive] Error 1
> make[3]: Leaving directory
> `/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3'
> make[2]: *** [all] Error 2
> make[2]: Leaving directory
> `/tmp/gcc-obj/ia64-unknown-linux-gnu/libstdc++-v3'
> make[1]: *** [all-target-libstdc++-v3] Error 2
> make[1]: Leaving directory `/tmp/gcc-obj'
> make: *** [bootstrap] Error 2
>
> see PR13766.
>
> Richard.
>

Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)

[Richard Henderson]

On Tue, Jan 20, 2004 at 11:52:07PM +0100, Richard Guenther wrote:
> I just checked 3.4 branch and get exactly the same failure.  And I can't
> find any trace of _Unwind_Resume_or_Rethrow being defined or used anywhere
> but as extern declaration in unwind.h ...

It's in unwind.inc.

> anyone has an idea what I'm doing wrong? This is Debian unstable, binutils
> is 2.14.90.0.7-3, libc 2.3.2.ds1-10.0.

Did you configure for libunwind, and not have a version that
is up-to-date enough to provide this symbol?


r~

Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)

[Richard Guenther]

On Tue, 20 Jan 2004, Richard Henderson wrote:

> On Tue, Jan 20, 2004 at 11:52:07PM +0100, Richard Guenther wrote:
> > I just checked 3.4 branch and get exactly the same failure.  And I can't
> > find any trace of _Unwind_Resume_or_Rethrow being defined or used anywhere
> > but as extern declaration in unwind.h ...
>
> It's in unwind.inc.
>
> > anyone has an idea what I'm doing wrong? This is Debian unstable, binutils
> > is 2.14.90.0.7-3, libc 2.3.2.ds1-10.0.
>
> Did you configure for libunwind, and not have a version that
> is up-to-date enough to provide this symbol?

Ah, ok.  But shouldn't detect configure this problem and disable support
for libunwind then?  Also the mentioned --disable-libunwind-exceptions
workaround is not documented in install.texi, instead there is a note
for ia64 which reads "If you are using the optional libunwind library,
                                           ^^^^^^^^
then you must use libunwind 0.96 or later." which suggests, I have to
enable this manually, not fix a wrong configure guess with
--disable-libunwind-exceptions.

Ugh. I see where this libunwind is coming from... it's from a Intel 8.0
compiler installation in /usr/local/lib...

Well, something like

Index: configure.ac
===================================================================
RCS file: /cvs/gcc/gcc/gcc/configure.ac,v
retrieving revision 2.6.2.2
diff -u -c -r2.6.2.2 configure.ac
*** configure.ac	19 Jan 2004 17:01:31 -0000	2.6.2.2
--- configure.ac	21 Jan 2004 10:30:05 -0000
***************
*** 973,979 ****
    [Define 0/1 to force the choice for exception handling model.])])

  if test x$host = x$target; then
!    AC_CHECK_LIB(unwind, main, use_libunwind_default=yes, use_libunwind_default=no)
  else
     use_libunwind_default=no
  fi
--- 973,979 ----
    [Define 0/1 to force the choice for exception handling model.])])

  if test x$host = x$target; then
!    AC_CHECK_LIB(unwind, _Unwind_Resume_or_Rethrow, use_libunwind_default=yes, use_libunwind_default=no)
  else
     use_libunwind_default=no
  fi

should help, as we diverge from the standards libunwind requirements
(untested).

Richard.

--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)

[Jim Wilson]

Richard Guenther wrote:
> Ah, ok.  But shouldn't detect configure this problem and disable support
> for libunwind then?

We tried that.  We couldn't get it to work.

>  Also the mentioned --disable-libunwind-exceptions
> workaround is not documented in install.texi, instead there is a note
> for ia64 which reads "If you are using the optional libunwind library,

It is optional in the sense that gcc will work without it.  However, 
since libunwind is better than gcc's builtin unwinder, it is used by 
default if it exists.

> then you must use libunwind 0.96 or later." which suggests, I have to
> enable this manually, not fix a wrong configure guess with
> --disable-libunwind-exceptions.

It would be reasonable to modify the documentation to mention this 
configure option.  Would you like to suggest some wording?

There are no known OS releases that ship any version of libunwind before 
0.96 so it was believed that this would not be a serious inconvenience 
for anyone.  You are the first to report the conflict with the Intel 
compiler.  This is unfortunate.  We may have to do something to address 
this problem if updating the documentation is not enough.

Incidentally, the change to require 0.96 was done at the request of the 
libunwind author (and linux kernel maintainer) David Mosberger, because 
he believed the advantages of requiring 0.96 outweighed the disadvantages.

> !    AC_CHECK_LIB(unwind, _Unwind_Resume_or_Rethrow, use_libunwind_default=yes, use_libunwind_default=no)

We already tried that.  It doesn't work.  This uses the currently 
installed compiler to link a testcase with libunwind.  If the currently 
installed compiler is working, then it will provide a copy of 
_Unwind_Resume_or_Rethrow if libunwind does not have it, and thus this 
test always succeeds making it useless.

We can make this work if we directly run nm on the library instead of 
doing a link first.  However, that begs the question of how to find the 
library if we don't run the linker, and I don't know how to solve that 
problem.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)

[Richard Guenther]

On Wed, 21 Jan 2004, Jim Wilson wrote:

> > !    AC_CHECK_LIB(unwind, _Unwind_Resume_or_Rethrow, use_libunwind_default=yes, use_libunwind_default=no)
>
> We already tried that.  It doesn't work.  This uses the currently
> installed compiler to link a testcase with libunwind.  If the currently
> installed compiler is working, then it will provide a copy of
> _Unwind_Resume_or_Rethrow if libunwind does not have it, and thus this
> test always succeeds making it useless.

Well, in my case, gcc 3.3 wouldn't have _Unwind_Resume_or_Rethrow and
Intel libunwind, too, so it would have catched this case at least.  I.e.
using the check as above will not miss libunwind that is ok more than the
test before, but _may_ detect incompatible libunwind.  I.e. it's always
better.

Richard.

> We can make this work if we directly run nm on the library instead of
> doing a link first.  However, that begs the question of how to find the
> library if we don't run the linker, and I don't know how to solve that
> problem.
> --
> Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
>

Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)

[Jim Wilson]

Richard Guenther wrote:
> Well, in my case, gcc 3.3 wouldn't have _Unwind_Resume_or_Rethrow and
> Intel libunwind, too, so it would have catched this case at least.

gcc-3.3 does have _Unwind_Resume_or_Rethrow.  I don't see how this can 
work when 3.3 is the bootstrap compiler.  My IA-64 build machine runs 
debian testing which uses gcc-3.3 as the system compiler, so I believe I 
have already tested this and shown that it can't work, though it is 
possible that I made a mistake somewhere.

> I.e. it's always better.

I think that is arguable.  It is harder to write the documention if you 
have a configure test and will sometimes work and sometimes fail to 
work, as opposed to one that always fails.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Readiness of tree-ssa

[Diego Novillo]

On Tue, 2004-01-20 at 14:48, Wolfgang Bangerth wrote:
> Just as another datapoint: we've got a number of people routinely compiling 
> and running applications nightly. Off the top of my head, this would be 
> Gerald, Guenther (POOMA), and me, and I'm certainly missing more. As far as I 
> can see none of us has had much success with tree-ssa yet. 
> 
We've been building DLV nightly and it seems to work.  The last build
was on Jan/17.  Has it broken since then?

We're having some problems building POOMA, though they seem
configuration related.  Brian, have you had any luck with it?

> I understand and appreciate that the tree-ssa people are putting a significant 
> amount of work into the branch. However, I'd like to propose postponing the 
> merge until at least the testers inside the gcc project are reasonably happy 
> with the branch. Whatever they will find, we'll get as reports later anyway, 
> but this way we could make sure that it's fixed before it propagates to the 
> mainline.
> 
Is there a PR for the problems you're having with your code?  I'd like
to have PRs for all the major problems people are seeing with the
branch.  We could then have a blocker PR that depends on all of those
that we agree should be addressed before the merge or immediately after
the merge.

Let's face it, when we merge the branch, we expect to have some amount
of fixing work to do.  We can't pretend that the code will be releasable
by then.  But we need to make sure that we merge in a state where the
problems are manageable.


Thanks.  Diego.

Re: Readiness of tree-ssa

[Wolfgang Bangerth]

> We've been building DLV nightly and it seems to work.  The last build
> was on Jan/17.  Has it broken since then?

I only have this mail from him:
  http://gcc.gnu.org/ml/gcc/2004-01/msg00657.html
This is from 2004-01-11, so may well be outdated already.


> We're having some problems building POOMA, though they seem
> configuration related.  Brian, have you had any luck with it?

Richard didn't seem too happy:
  http://gcc.gnu.org/ml/gcc/2004-01/msg01545.html


> Is there a PR for the problems you're having with your code?

I gave it in my mail. It's PR 13681. Steven already analyzed it, but since 
then it's been sitting idle.


> Let's face it, when we merge the branch, we expect to have some amount
> of fixing work to do.  We can't pretend that the code will be releasable
> by then.  But we need to make sure that we merge in a state where the
> problems are manageable.

But that's exactly the point -- to figure out which state the branch it is in, 
it would be nice if those people that find a non-negligible number of our 
bugs before something is actually released, could actually test the branch. I 
understand that tree-ssa is able to compile and run a significant number of 
applications at the moment, but the fact that the application testers inside 
gcc are not satisfied at the moment indicates that there is some work still 
to be done.

I have a nightly tester that I'd like to run, but that only makes sense if I 
can compile my application. I'll make you the following deal: you make my 
application compile, and I'll make sure that within a few days I'll get to 
check whether and how many miscompilations I have, and file PRs for each of 
them. Then we'll have a clearer picture of the state of the branch. I could 
imagine that other application testers would do similar things.

This way the total number of bugs to be fixed is the same as if we merged now, 
but we'll have less disruption of mainline.

Regards
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Readiness of tree-ssa

[Diego Novillo]

On Wed, 2004-01-21 at 15:16, Wolfgang Bangerth wrote:

> > We're having some problems building POOMA, though they seem
> > configuration related.  Brian, have you had any luck with it?
> 
> Richard didn't seem too happy:
>   http://gcc.gnu.org/ml/gcc/2004-01/msg01545.html
> 
So, POOMA does work now, good.  I meant configuration problems,
actually.  The nightly tester we have seems to get into trouble
configuring POOMA.
> 
> > Is there a PR for the problems you're having with your code?
> 
> I gave it in my mail. It's PR 13681. Steven already analyzed it, but since 
> then it's been sitting idle.
> 
OK, thanks.


> > Let's face it, when we merge the branch, we expect to have some amount
> > of fixing work to do.  We can't pretend that the code will be releasable
> > by then.  But we need to make sure that we merge in a state where the
> > problems are manageable.
> 
> But that's exactly the point -- to figure out which state the branch it is in, 
>
We are in violent agreement.  Now, what I'd like to know is what of the
existing PRs do people consider blockers for inclusion into mainline. 
That's the consensus I want to reach.  I will try and find those that I
would like to fix prior to the merge and post them here.

Does bugzilla have a voting mechanism?  We are probably not going to fix
*all* the PRs prior to merging.  It reaches a point of diminishing
returns where we have stuff breaking because of changes in mainline
and/or enough drift to make the merge increasingly more difficult.


Diego.

Re: Readiness of tree-ssa

[Wolfgang Bangerth]

> We are in violent agreement.  Now, what I'd like to know is what of the
> existing PRs do people consider blockers for inclusion into mainline.

Obviously 13681 is annoying me :-)

I don't know what other PRs are important to me, since I haven't yet been able 
to file any about miscompilations etc.


> Does bugzilla have a voting mechanism?  We are probably not going to fix
> *all* the PRs prior to merging.

You can use the priority/severity fields for this. However, my understanding 
was that merging a branch usually requires zero new regressions. I think you 
can't unilaterally decide which bugs you'd like to fix before merging.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Readiness of tree-ssa

[Diego Novillo]

On Wed, 2004-01-21 at 15:46, Wolfgang Bangerth wrote:

> > Does bugzilla have a voting mechanism?  We are probably not going to fix
> > *all* the PRs prior to merging.
> 
> You can use the priority/severity fields for this. However, my understanding 
> was that merging a branch usually requires zero new regressions. I think you 
> can't unilaterally decide which bugs you'd like to fix before merging.
> 
I didn't mean that.  I was taking the other criteria for granted.


Diego.

Re: Readiness of tree-ssa

[Paul Jarc]

Wolfgang Bangerth <bangerth@ices.utexas.edu> wrote:
> However, my understanding was that merging a branch usually requires
> zero new regressions.

Just a thought: one new regression could be allowed for each
regression that is fixed on the branch but not on mainline - so zero
*net* new regressions.  I don't remember exactly whether there are any
in this case anyway.


paul

Re: Readiness of tree-ssa

[Daniel Berlin]

> Does bugzilla have a voting mechanism?

Yes.
I just have it turned off.
If people want me to turn it on, i will.

Re: Readiness of tree-ssa

[Gabriel Dos Reis]

Daniel Berlin <dberlin@dberlin.org> writes:

| > Does bugzilla have a voting mechanism?
| 
| Yes.
| I just have it turned off.
| If people want me to turn it on, i will.

Please, please, let's not manage GCC based on hits in bugzilla.
There are various ways to look at numbers and one can make them say
nearly anything.

-- Gaby

Re: Readiness of tree-ssa

[Wolfgang Bangerth]

On Wednesday 21 January 2004 03:15 pm, Gabriel Dos Reis wrote:
> Daniel Berlin <dberlin@dberlin.org> writes:
> | > Does bugzilla have a voting mechanism?
> |
> | Yes.
> | I just have it turned off.
> | If people want me to turn it on, i will.
>
> Please, please, let's not manage GCC based on hits in bugzilla.
> There are various ways to look at numbers and one can make them say
> nearly anything.

I agree. Out priority should be to fix regressions. Once we're done with that 
we can again think about ordering teh other bugs.

W.

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Readiness of tree-ssa

[Daniel Berlin]

On Jan 21, 2004, at 4:15 PM, Gabriel Dos Reis wrote:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
> | > Does bugzilla have a voting mechanism?
> |
> | Yes.
> | I just have it turned off.
> | If people want me to turn it on, i will.
>
> Please, please, let's not manage GCC based on hits in bugzilla.
> There are various ways to look at numbers and one can make them say
> nearly anything.

I'm staying neutral here, since i don't really have much preference 
either way (it obviously has benefits and disadvantages). I'm just 
stating a fact in response to his question.
:)

>
> -- Gaby

Re: Readiness of tree-ssa

[Wolfgang Bangerth]

On Wednesday 21 January 2004 02:16 pm, Wolfgang Bangerth wrote:

> I have a nightly tester that I'd like to run, but that only makes sense if
> I can compile my application. I'll make you the following deal: you make my
> application compile, and I'll make sure that within a few days I'll get to
> check whether and how many miscompilations I have, and file PRs for each of
> them. 

Just as a follow-up to myself: Richard was so kind to fix PR 13681 (and 13772 
as an unnoticed side effect) -- many thanks!

I'll see what bugs I can come up with next.

Thanks
  Wolfgang

-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/

Re: Readiness of tree-ssa

[Gerald Pfeifer]

On Wed, 21 Jan 2004, Wolfgang Bangerth wrote:
>> We've been building DLV nightly and it seems to work.  The last build
>> was on Jan/17.  Has it broken since then?
> I only have this mail from him:
>   http://gcc.gnu.org/ml/gcc/2004-01/msg00657.html
> This is from 2004-01-11, so may well be outdated already.

I'm still suffering from the invalid code generation issue, though
testing has been delayed a bit due to the bootstrap failure of tree-ssa
on SPARC, the fixinc regression on Solaris (fixed on mainline and waiting
for the next merger from mainline), and the recent breakage of mainline.

Only one of these is actually closely related to tree-ssa, but testing
GCC with real-world appliations is getting a bit tought these days,
overall. :-(

In a sense, tree-ssa is now suffering from mainline being unstable and
partly broken, where the original issue was to avoid tree-ssa making
mainline unstable.

Gerald

> But that's exactly the point -- to figure out which state the branch it
> is in, it would be nice if those people that find a non-negligible
> number of our bugs before something is actually released, could actually
> test the branch.

DLV, I believe, has in the last six years lead to about 200+ bug reports
for GCC. :-/

Re: Readiness of tree-ssa

[Wolfgang Bangerth]

> I'm still suffering from the invalid code generation issue,

Some initial testing: About a half a dozen of my testcases produce wrong 
results, hang, or abort already in non-optimized mode :-( Some of them seem 
related, though. I'll investigate these first, before trying to switch on 
optimization.

Regards
  Wolfgang
 
-------------------------------------------------------------------------
Wolfgang Bangerth              email:            bangerth@ices.utexas.edu
                               www: http://www.ices.utexas.edu/~bangerth/