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 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
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 changes
Steven Bosscher wrote:
On 4/16/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
29841 [4.2/4.3 regression] ICE with scheduling and __builtin_trap
Honza, PING!
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
30786 is ICE-on-invalid. 30805 is ICE-on-unspecified.
I don't like ICEs but these don't seem like release-blockers to me.
Anyway I attached prototype patches for these. I don't have resources
to test them for three weeks, so if anybody can beat me to it...
Paolo
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
> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
Steven> * Maintainers of certain areas of the compiler may not be
Steven> sufficiently aware of some bug in their part of the
Steven> compiler. For example, only one of the three preprocessor bugs
Steven> is assigned to a preprocessor m
> "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 easi
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
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
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
>> HOWTO for these scripts (or ask someone to do it). Regression hu
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
> HOWTO for these scripts (or ask someone to do it). Regression hunting
> should only be eas
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 4.
> 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
> introd
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
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 generate
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???
Why don't you ever go and actually *find something out* about what
you're talking ab
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???
Why don't you ever go and actually *find something out* about what
you're talking about before you spout nonsense all over the list?
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
teste
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 u
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
commit.
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 y
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 script
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 yo
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
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 -000
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 b
> -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 respons
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)
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 regr
> > 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 he
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; p
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! -- the
33 matches
Mail list logo
