On 4/17/07, Maxim Kuvyrkov [EMAIL PROTECTED] wrote:
There is a patch for this PR29841 in
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html . The problem
is that I don't really know which maintainer ask to review it :(
I think this patch needs re-testing (because of my cfglayout
On 4/17/07, Steven Bosscher [EMAIL PROTECTED] wrote:
On 4/17/07, Maxim Kuvyrkov [EMAIL PROTECTED] wrote:
There is a patch for this PR29841 in
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01134.html . The problem
is that I don't really know which maintainer ask to review it :(
I think this
On 4/17/07, Richard Guenther [EMAIL PROTECTED] wrote:
Indeed. The patch is ok after a re-bootstrap and re-test.
Actually, please don't commit that patch.
Eric Botcazou has already proposed a fix that looks better:
http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01065.html
Gr.
Steven
On Mon, Apr 16, 2007 at 10:09:35PM +0200, Laurent GUERBY wrote:
On Mon, 2007-04-16 at 12:00 -0600, Tom Tromey wrote:
I wonder whether there is a role for the gcc compile farm in this?
For instance perhaps someone could keep a set of builds there and
provide folks with a simple way to
You want more bugs fixed, it would seem a better way would be to build
a better sense of community (Have bugfix-only days, etc) and encourage
it through good behavior, not through negative reinforcement.
I do agree with that in a general way, but I think there should also
be a real effort done
Installed.
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.607
diff -u -3 -p -r1.607 index.html
--- index.html 23 Mar 2007 08:31:00 - 1.607
+++ index.html 16 Apr 2007 08:51:28
2007/4/16, François-Xavier Coudert [EMAIL PROTECTED] wrote:
You want more bugs fixed, it would seem a better way would be to build
a better sense of community (Have bugfix-only days, etc) and encourage
it through good behavior, not through negative reinforcement.
I do agree with that in a
The mea culpa is to permit for long time to modify configure instead of
configure.ac or configure.in that is used by autoconf and/or automake.
[...]
I'm sorry, but I don't understand at all what you propose, what your
proposal is supposed to fix or how that is related to the mail you're
On 4/16/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
The mea culpa is to permit for long time to modify configure instead of
configure.ac or configure.in that is used by autoconf and/or automake.
Another mea culpa is don't update the autoconf/automake versions when
the GCC''s scripts are using
2007/4/16, François-Xavier Coudert [EMAIL PROTECTED] wrote:
The mea culpa is to permit for long time to modify configure instead of
configure.ac or configure.in that is used by autoconf and/or automake.
[...]
I'm sorry, but I don't understand at all what you propose, what your
proposal is
libdecnumber/aclocal.m4:# generated automatically by aclocal 1.9.5 -*-
Autoconf -*-
That's a problem in the last regeneration of this file. I'm CCing M.
Meissner, H. J. Lu and M. Cornea, since they appear to have last
changed this file, although there's no ChangeLog entry for it in their
2007/4/16, Andrew Pinski [EMAIL PROTECTED] wrote:
On 4/16/07, J.C. Pizarro [EMAIL PROTECTED] wrote:
The mea culpa is to permit for long time to modify configure instead of
configure.ac or configure.in that is used by autoconf and/or automake.
Another mea culpa is don't update the
2007/4/16, François-Xavier Coudert [EMAIL PROTECTED] wrote:
1) To update the generated configure scripts of the tarball before
than distributing it.
It could be done, but there's the risk that an automated process like
that might introduce problems. I'd be more in favour of a nightly
tester
On 16 April 2007 10:56, J.C. Pizarro wrote:
The GCC scripts use autotools but the site don't use autotools because
it says which is inconvenient. What???
sigh Why don't you ever go and actually *find something out* about what
you're talking about before you spout nonsense all over the
2007/4/16, Dave Korn [EMAIL PROTECTED] wrote:
On 16 April 2007 10:56, J.C. Pizarro wrote:
The GCC scripts use autotools but the site don't use autotools because
it says which is inconvenient. What???
sigh Why don't you ever go and actually *find something out* about what
you're talking
On 16 April 2007 11:17, J.C. Pizarro wrote:
I follow,
No, not very well.
The end-users who just want to compile gcc from a tarball do not
have to have autoconf installed, because we supply all the generated files
for them in the tarball. - Well,
what is the matter if the generated
2007/4/16, Dave Korn [EMAIL PROTECTED] wrote:
On 16 April 2007 11:17, J.C. Pizarro wrote:
I follow,
No, not very well.
The end-users who just want to compile gcc from a tarball do not
have to have autoconf installed, because we supply all the generated files
for them in the tarball. -
Also, beyond that, I would strongly suspect that these PRs haven't been
fixed in large part because they're difficult to track down, and
possibly if we knew what commit had introduced them, we'd be a good bit
farther along in fixing them, even without having the help of whoever
introduced
On 4/16/07, Mark Mitchell [EMAIL PROTECTED] wrote:
29841 [4.2/4.3 regression] ICE with scheduling and __builtin_trap
Honza, PING!
31360 [4.2/4.3 Regression] rtl loop invariant is broken
Zdenek, PING!
The broader question of why there are so many 124 P3 or higher
regressions against
On Mon, Apr 16, 2007 at 10:58:13AM -0700, Mark Mitchell wrote:
Janis Johnson wrote:
On Mon, Apr 16, 2007 at 06:36:07PM +0200, Steven Bosscher wrote:
* Very few people know how to use Janis' scripts, so to encourage
people to use them, the release manager could write a wiki page with a
Janis Johnson wrote:
The RM can encourage me to do this; I've already been meaning to for a
long time now.
You may certainly consider yourself encouraged. :-)
Gosh, thanks!
:-)
I have IBM permission to contribute them to GCC. An earlier version for
CVS is in contrib/reghunt with formal
Janis == Janis Johnson [EMAIL PROTECTED] writes:
* Very few people know how to use Janis' scripts, so to encourage
people to use them, the release manager could write a wiki page with a
HOWTO for these scripts (or ask someone to do it). Regression hunting
should only be easier now, with
On 4/16/07, Janis Johnson [EMAIL PROTECTED] wrote:
I'd like at least two volunteers to help me with this cleanup and
documentation effort by using my current scripts on regressions for
open PRs and finding the places that are specific to my environment.
Since I brought this up, I guess I'm on
We're a bit short on the current CompileFarm machines,
we have 5x16GB + 4x32GB (and as shown below it tends to
be used, I have to ping users from time to time to get GB
back :).
There is enough cpu power in the farm to build and check a version for
each commit (all languages including Ada) on up
As has been remarked on the GCC mailing lists, I've not succeeded in
getting GCC 4.2.0 out the door. However, with the limited criteria that
we target only P1 regressions not present in 4.1.x, we seem to be
getting a bit closer. The only regressions in this category are:
26792 [4.2 Regression]
On 15 April 2007 23:51, Mark Mitchell wrote:
The broader question of why there are so many 124 P3 or higher
regressions against 4.2.0 points to a more fundamental problem.
Despite the fact that virtually all of the bugs open against 4.2.0 are
also open against 4.1 or 4.3 -- or both! -- there
Dave Korn wrote:
Some have suggested that I try to solve this by closing GCC 4.3
development until 4.2.0 is done. I've considered that, but I don't
think it's a good idea. In practice, this whole software freedom thing
means that people can go off and do things on their own anyhow; people
Despite the fact that virtually all of the bugs open against 4.2.0 are
also open against 4.1 or 4.3 -- or both! -- there seems to be little
interest in fixing them.
Some have suggested that I try to solve this by closing GCC 4.3
development until 4.2.0 is done.
So here's a second
On 4/15/07, Mark Mitchell [EMAIL PROTECTED] wrote:
As has been remarked on the GCC mailing lists, I've not succeeded in
getting GCC 4.2.0 out the door. However, with the limited criteria that
we target only P1 regressions not present in 4.1.x, we seem to be
getting a bit closer. The only
Daniel Berlin wrote:
On 4/15/07, Mark Mitchell [EMAIL PROTECTED] wrote:
However, I would consider asking the SC for permission to institute a
rule that would prevent contributors responsible for P1 bugs (in the
only possible bright-line sense: that the bug appeared as a result of
their patch)
-Original Message-
From: Mark Mitchell [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 15, 2007 4:51 PM
To: GCC
Subject: GCC 4.2.0 Status Report (2007-04-15)
However, I would consider asking the SC for permission to institute a
rule that would prevent contributors responsible
31 matches
Mail list logo
