* Readiness of tree-ssa
@ 2004-01-20 19:48 Wolfgang Bangerth
2004-01-20 20:00 ` Richard Guenther
2004-01-21 19:44 ` Readiness of tree-ssa Diego Novillo
0 siblings, 2 replies; 23+ messages in thread
From: Wolfgang Bangerth @ 2004-01-20 19:48 UTC (permalink / raw)
To: gcc; +Cc: Gerald Pfeifer, rguenth
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/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-20 19:48 Readiness of tree-ssa Wolfgang Bangerth
@ 2004-01-20 20:00 ` Richard Guenther
2004-01-20 20:07 ` Diego Novillo
2004-01-21 19:44 ` Readiness of tree-ssa Diego Novillo
1 sibling, 1 reply; 23+ messages in thread
From: Richard Guenther @ 2004-01-20 20:00 UTC (permalink / raw)
To: Wolfgang Bangerth; +Cc: gcc, Gerald Pfeifer, rguenth
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-20 20:00 ` Richard Guenther
@ 2004-01-20 20:07 ` Diego Novillo
2004-01-20 21:55 ` Richard Guenther
0 siblings, 1 reply; 23+ messages in thread
From: Diego Novillo @ 2004-01-20 20:07 UTC (permalink / raw)
To: Richard Guenther; +Cc: Wolfgang Bangerth, gcc, Gerald Pfeifer
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-20 20:07 ` Diego Novillo
@ 2004-01-20 21:55 ` Richard Guenther
2004-01-20 22:52 ` Bootstrap failures on ia64 (was Re: Readiness of tree-ssa) Richard Guenther
0 siblings, 1 reply; 23+ messages in thread
From: Richard Guenther @ 2004-01-20 21:55 UTC (permalink / raw)
To: Diego Novillo; +Cc: Wolfgang Bangerth, gcc, Gerald Pfeifer
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)
2004-01-20 21:55 ` Richard Guenther
@ 2004-01-20 22:52 ` Richard Guenther
2004-01-21 0:20 ` Richard Henderson
0 siblings, 1 reply; 23+ messages in thread
From: Richard Guenther @ 2004-01-20 22:52 UTC (permalink / raw)
To: Richard Guenther; +Cc: Diego Novillo, gcc
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.
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)
2004-01-20 22:52 ` Bootstrap failures on ia64 (was Re: Readiness of tree-ssa) Richard Guenther
@ 2004-01-21 0:20 ` Richard Henderson
2004-01-21 11:12 ` Richard Guenther
0 siblings, 1 reply; 23+ messages in thread
From: Richard Henderson @ 2004-01-21 0:20 UTC (permalink / raw)
To: Richard Guenther; +Cc: Diego Novillo, gcc
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~
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)
2004-01-21 0:20 ` Richard Henderson
@ 2004-01-21 11:12 ` Richard Guenther
2004-01-21 18:52 ` Jim Wilson
0 siblings, 1 reply; 23+ messages in thread
From: Richard Guenther @ 2004-01-21 11:12 UTC (permalink / raw)
To: Richard Henderson; +Cc: Diego Novillo, gcc
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/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)
2004-01-21 11:12 ` Richard Guenther
@ 2004-01-21 18:52 ` Jim Wilson
2004-01-21 22:12 ` Richard Guenther
0 siblings, 1 reply; 23+ messages in thread
From: Jim Wilson @ 2004-01-21 18:52 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-20 19:48 Readiness of tree-ssa Wolfgang Bangerth
2004-01-20 20:00 ` Richard Guenther
@ 2004-01-21 19:44 ` Diego Novillo
2004-01-21 20:38 ` Wolfgang Bangerth
1 sibling, 1 reply; 23+ messages in thread
From: Diego Novillo @ 2004-01-21 19:44 UTC (permalink / raw)
To: Wolfgang Bangerth; +Cc: gcc, Gerald Pfeifer, Richard Guenther, Brian Booth
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 19:44 ` Readiness of tree-ssa Diego Novillo
@ 2004-01-21 20:38 ` Wolfgang Bangerth
2004-01-21 20:46 ` Diego Novillo
` (2 more replies)
0 siblings, 3 replies; 23+ messages in thread
From: Wolfgang Bangerth @ 2004-01-21 20:38 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc, Gerald Pfeifer, Richard Guenther, Brian Booth
> 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/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 20:38 ` Wolfgang Bangerth
@ 2004-01-21 20:46 ` Diego Novillo
2004-01-21 20:50 ` Wolfgang Bangerth
2004-01-21 21:13 ` Daniel Berlin
2004-01-22 17:27 ` Wolfgang Bangerth
2004-01-23 14:37 ` Gerald Pfeifer
2 siblings, 2 replies; 23+ messages in thread
From: Diego Novillo @ 2004-01-21 20:46 UTC (permalink / raw)
To: Wolfgang Bangerth; +Cc: gcc, Gerald Pfeifer, Richard Guenther, Brian Booth
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 20:46 ` Diego Novillo
@ 2004-01-21 20:50 ` Wolfgang Bangerth
2004-01-21 20:52 ` Diego Novillo
2004-01-21 20:59 ` Paul Jarc
2004-01-21 21:13 ` Daniel Berlin
1 sibling, 2 replies; 23+ messages in thread
From: Wolfgang Bangerth @ 2004-01-21 20:50 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc, Gerald Pfeifer, Richard Guenther, Brian Booth
> 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/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 20:50 ` Wolfgang Bangerth
@ 2004-01-21 20:52 ` Diego Novillo
2004-01-21 20:59 ` Paul Jarc
1 sibling, 0 replies; 23+ messages in thread
From: Diego Novillo @ 2004-01-21 20:52 UTC (permalink / raw)
To: Wolfgang Bangerth; +Cc: gcc, Gerald Pfeifer, Richard Guenther, Brian Booth
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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 20:50 ` Wolfgang Bangerth
2004-01-21 20:52 ` Diego Novillo
@ 2004-01-21 20:59 ` Paul Jarc
1 sibling, 0 replies; 23+ messages in thread
From: Paul Jarc @ 2004-01-21 20:59 UTC (permalink / raw)
To: Wolfgang Bangerth
Cc: Diego Novillo, gcc, Gerald Pfeifer, Richard Guenther, Brian Booth
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 20:46 ` Diego Novillo
2004-01-21 20:50 ` Wolfgang Bangerth
@ 2004-01-21 21:13 ` Daniel Berlin
2004-01-21 21:30 ` Gabriel Dos Reis
1 sibling, 1 reply; 23+ messages in thread
From: Daniel Berlin @ 2004-01-21 21:13 UTC (permalink / raw)
To: Diego Novillo
Cc: Wolfgang Bangerth, gcc, Brian Booth, Richard Guenther, Gerald Pfeifer
> Does bugzilla have a voting mechanism?
Yes.
I just have it turned off.
If people want me to turn it on, i will.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 21:13 ` Daniel Berlin
@ 2004-01-21 21:30 ` Gabriel Dos Reis
2004-01-21 21:31 ` Wolfgang Bangerth
2004-01-21 21:38 ` Daniel Berlin
0 siblings, 2 replies; 23+ messages in thread
From: Gabriel Dos Reis @ 2004-01-21 21:30 UTC (permalink / raw)
To: Daniel Berlin
Cc: Diego Novillo, Wolfgang Bangerth, gcc, Brian Booth,
Richard Guenther, Gerald Pfeifer
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 21:30 ` Gabriel Dos Reis
@ 2004-01-21 21:31 ` Wolfgang Bangerth
2004-01-21 21:38 ` Daniel Berlin
1 sibling, 0 replies; 23+ messages in thread
From: Wolfgang Bangerth @ 2004-01-21 21:31 UTC (permalink / raw)
To: Gabriel Dos Reis, Daniel Berlin
Cc: Diego Novillo, gcc, Brian Booth, Richard Guenther, Gerald Pfeifer
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/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 21:30 ` Gabriel Dos Reis
2004-01-21 21:31 ` Wolfgang Bangerth
@ 2004-01-21 21:38 ` Daniel Berlin
1 sibling, 0 replies; 23+ messages in thread
From: Daniel Berlin @ 2004-01-21 21:38 UTC (permalink / raw)
To: Gabriel Dos Reis
Cc: Wolfgang Bangerth, gcc, Brian Booth, Richard Guenther,
Diego Novillo, Gerald Pfeifer
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)
2004-01-21 18:52 ` Jim Wilson
@ 2004-01-21 22:12 ` Richard Guenther
2004-01-21 23:33 ` Jim Wilson
0 siblings, 1 reply; 23+ messages in thread
From: Richard Guenther @ 2004-01-21 22:12 UTC (permalink / raw)
To: Jim Wilson; +Cc: Richard Guenther, gcc
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
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Bootstrap failures on ia64 (was Re: Readiness of tree-ssa)
2004-01-21 22:12 ` Richard Guenther
@ 2004-01-21 23:33 ` Jim Wilson
0 siblings, 0 replies; 23+ messages in thread
From: Jim Wilson @ 2004-01-21 23:33 UTC (permalink / raw)
To: Richard Guenther; +Cc: gcc
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
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 20:38 ` Wolfgang Bangerth
2004-01-21 20:46 ` Diego Novillo
@ 2004-01-22 17:27 ` Wolfgang Bangerth
2004-01-23 14:37 ` Gerald Pfeifer
2 siblings, 0 replies; 23+ messages in thread
From: Wolfgang Bangerth @ 2004-01-22 17:27 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc, Gerald Pfeifer, Richard Guenther, Brian Booth, rth
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/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-21 20:38 ` Wolfgang Bangerth
2004-01-21 20:46 ` Diego Novillo
2004-01-22 17:27 ` Wolfgang Bangerth
@ 2004-01-23 14:37 ` Gerald Pfeifer
2004-01-23 17:01 ` Wolfgang Bangerth
2 siblings, 1 reply; 23+ messages in thread
From: Gerald Pfeifer @ 2004-01-23 14:37 UTC (permalink / raw)
To: Wolfgang Bangerth; +Cc: Diego Novillo, gcc, Richard Guenther, Brian Booth
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. :-/
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Readiness of tree-ssa
2004-01-23 14:37 ` Gerald Pfeifer
@ 2004-01-23 17:01 ` Wolfgang Bangerth
0 siblings, 0 replies; 23+ messages in thread
From: Wolfgang Bangerth @ 2004-01-23 17:01 UTC (permalink / raw)
To: Gerald Pfeifer; +Cc: Diego Novillo, gcc, Richard Guenther, Brian Booth
> 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/
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2004-01-23 16:51 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-20 19:48 Readiness of tree-ssa Wolfgang Bangerth
2004-01-20 20:00 ` Richard Guenther
2004-01-20 20:07 ` Diego Novillo
2004-01-20 21:55 ` Richard Guenther
2004-01-20 22:52 ` Bootstrap failures on ia64 (was Re: Readiness of tree-ssa) Richard Guenther
2004-01-21 0:20 ` Richard Henderson
2004-01-21 11:12 ` Richard Guenther
2004-01-21 18:52 ` Jim Wilson
2004-01-21 22:12 ` Richard Guenther
2004-01-21 23:33 ` Jim Wilson
2004-01-21 19:44 ` Readiness of tree-ssa Diego Novillo
2004-01-21 20:38 ` Wolfgang Bangerth
2004-01-21 20:46 ` Diego Novillo
2004-01-21 20:50 ` Wolfgang Bangerth
2004-01-21 20:52 ` Diego Novillo
2004-01-21 20:59 ` Paul Jarc
2004-01-21 21:13 ` Daniel Berlin
2004-01-21 21:30 ` Gabriel Dos Reis
2004-01-21 21:31 ` Wolfgang Bangerth
2004-01-21 21:38 ` Daniel Berlin
2004-01-22 17:27 ` Wolfgang Bangerth
2004-01-23 14:37 ` Gerald Pfeifer
2004-01-23 17:01 ` Wolfgang Bangerth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).