Richard Guenther wrote:
On 2/21/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
To be honest, my instinct for the FSF is to take the 4% hit and get rid
of this nasty class of bugs. Users measure compiler quality by more
than just floating-point benchmarks; FP code is a relatively small
(albeit
On Wed, Feb 21, 2007 at 08:49:38AM -0800, Mark Mitchell wrote:
> I don't know how to evaluate Danny B's claims that these things are
> rare. We don't have nearly as a big a customer base as Red Hat or SuSE,
> and our customer base compiles a different class of applications on
> different hardware,
On Wed, Feb 21, 2007 at 11:00:00PM +0100, Richard Guenther wrote:
> Of course the speed of a compiler is measured on testcases where
> speed matters - and this is usually FP code. Now based on this reasoning
> we could (as CodeSourcery probably did) enable -fno-strict-aliasing by
> default, which
On 2/21/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
To be honest, my instinct for the FSF is to take the 4% hit and get rid
of this nasty class of bugs. Users measure compiler quality by more
than just floating-point benchmarks; FP code is a relatively small
(albeit important, and substantial)
On Mon, 19 Feb 2007, Brooks Moses wrote:
> The 4.2.0 release is fairly significant to GFortran. In my opinion, it's
> really the first 4.x release for which we have a mature Fortran compiler
FWIW, this is something I have clearly heard from FreeBSD ports
maintainers responsible for ports being b
Kaveh R. GHAZI wrote:
> We have to make a judgement about how serious this bug really is. Some
> people seem to think correctness *always* wins, I don't like absolutes,
> they are too limiting. I don't at all think performance always wins, but
> correctness of rare corner cases which comes at hi
On Wed, Feb 21, 2007 at 11:33:39AM -0500, Kaveh R. GHAZI wrote:
> My tolerance is pretty low. I'm relying on the fact that the bug occurs
> rarely in real code. I'm trying to reconcile your statement about
> customer feedback with Daniel B's claim here:
> http://gcc.gnu.org/ml/gcc/2007-02/msg0047
On Tue, 20 Feb 2007, Daniel Jacobowitz wrote:
> On Tue, Feb 20, 2007 at 06:23:14PM -0500, Kaveh R. GHAZI wrote:
> > No it doesn't need stating, at least not for me. :-) Sure nobody likes
> > bugs/miscompilations, but all compilers have them. We evaluate how
> > serious they are and whether a per
Gabriel Dos Reis wrote:
Andi Kleen <[EMAIL PROTECTED]> writes:
| "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
| >
| > And we don't want to arm our detractors with bad SPEC numbers. I can just
| > imagine the FUD spreading... we've got to fix it or backout.
So what if gcc is a bit behind som
On 2/21/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> 4.0 branched with critical flaws that were not noticed until 4.2.0 which
> is why we end up with the missed optimiation regression in the first place.
>
> So the question is do we want to correct the regressions or not, because
> right now
4.0 branched with critical flaws that were not noticed until 4.2.0 which
is why we end up with the missed optimiation regression in the first place.
So the question is do we want to correct the regressions or not, because
right now we sound like we don't. Which regression is more important?
Wr
>
>
> > > That said, I think it would not be bad to put 4.3 in stage3 mode until
> > > dataflow branch is ready and, at that point, rebranch 4.2 and soon
> > > after that merge dataflow branch.
>
> FWIW I agree with Vlad and Paolo Bonzini.
>
> It seems as if 4.2 was branched with critical flaws
> > That said, I think it would not be bad to put 4.3 in stage3 mode until
> > dataflow branch is ready and, at that point, rebranch 4.2 and soon
> > after that merge dataflow branch.
FWIW I agree with Vlad and Paolo Bonzini.
It seems as if 4.2 was branched with critical flaws (it happens, no
bi
Andi Kleen <[EMAIL PROTECTED]> writes:
| "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
| >
| > And we don't want to arm our detractors with bad SPEC numbers. I can just
| > imagine the FUD spreading... we've got to fix it or backout.
|
| For me as a gcc user miscompilations are far worse than ba
On 2/19/07, Joe Buck <[EMAIL PROTECTED]> wrote:
On Tue, Feb 20, 2007 at 12:27:42AM +, Joseph S. Myers wrote:
>... *All* releases seem to have the
> predictions that they are useless, should be skipped because the next
> release will be so much better in way X or Y, etc.; I think the question
On Tue, Feb 20, 2007 at 06:23:14PM -0500, Kaveh R. GHAZI wrote:
> No it doesn't need stating, at least not for me. :-) Sure nobody likes
> bugs/miscompilations, but all compilers have them. We evaluate how
> serious they are and whether a performance hit from a bug fix is worth it.
> My understan
Paweł Sikora wrote:
> Current development line of PLD-Linux uses 4.2 too.
Thanks for that information.
> Mark, could you add the PR30052 to your 4.2-TODO ?
Did you mean personally? If so, I have no particular plans to work on
this PR. I'm afraid that my GCC time is pretty limited, and I'm try
On Tue, 20 Feb 2007, Andi Kleen wrote:
> "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> >
> > And we don't want to arm our detractors with bad SPEC numbers. I can just
> > imagine the FUD spreading... we've got to fix it or backout.
>
> For me as a gcc user miscompilations are far worse than bad
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
>
> And we don't want to arm our detractors with bad SPEC numbers. I can just
> imagine the FUD spreading... we've got to fix it or backout.
For me as a gcc user miscompilations are far worse than bad SPEC numbers.
I never run SPEC, but if my programs
Paolo Bonzini wrote:
I am agree, benchmarking is evil. My favorite benchmark is gcc
because it is my tool and I work on it. Compilation of gcc from
Spec2000 is >12% slower with df including last Paolo's patches
(which are a really big improvement).
Interesting enough, 176.gcc has a pre
I am agree, benchmarking is evil. My favorite benchmark is gcc because
it is my tool and I work on it. Compilation of gcc from Spec2000 is
>12% slower with df including last Paolo's patches (which are a really
big improvement).
Interesting enough, 176.gcc has a pretty bad result for runti
On 2/20/07, Eric Botcazou <[EMAIL PROTECTED]> wrote:
> FWIW, in Apple distributed GCC 4.0.x, strict-aliasing is disabled by
> default when -O? is used because it breaks too much existing
> code (not just Apple internal code).
Much more than in 3.x?
I do not have data to answer this appropriate
> FWIW, in Apple distributed GCC 4.0.x, strict-aliasing is disabled by
> default when -O? is used because it breaks too much existing
> code (not just Apple internal code).
Much more than in 3.x?
--
Eric Botcazou
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking about can be worked around by using
-fno-strict-aliasing.
FWIW, in Apple distribute
Paolo Bonzini wrote:
In term of ports, yes I am agree. As the preformance even with last
Paolo's patches (some changes could be applied to the mainline too,
so it is not only about df), the branch compiler is still 8.7% slower
for SPECint2000 compilation on 2.66Ghz Core2 with
--enable-chec
In term of ports, yes I am agree. As the preformance even with last
Paolo's patches (some changes could be applied to the mainline too, so
it is not only about df), the branch compiler is still 8.7% slower for
SPECint2000 compilation on 2.66Ghz Core2 with --enable-check=release.
Just to str
Steven Bosscher wrote:
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>[Option 1] Instead of 4.2, we should backport some functionality from
>4.2 to the 4.1 branch, and call that 4.2.
>
>[Option 2] Instead of 4.2, we should skip 4.2, stabilize 4.3, and call
>that 4.2.
>
>[Option 3] Li
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>[Option 1] Instead of 4.2, we should backport some functionality from
>4.2 to the 4.1 branch, and call that 4.2.
>
>[Option 2] Instead of 4.2, we should skip 4.2, stabilize 4.3, and call
>that 4.2.
>
>[Option 3] Like (2), but create (the ne
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>
>> As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
>> bugs are pretty nasty it is hard to find a option to work around because
>> ali
Richard Guenther wrote:
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking a
On 2/20/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
As for proposal to revert the aliasing fixes on the 4.2, IMHO aliasing
bugs are pretty nasty it is hard to find a option to work around because
alias info is used in many optimizations.
All bugs we are talking about can be worked around b
Mark Mitchell wrote:
I've spent some time today looking at GCC 4.2.
I've heard various comments about whether or not it's worth doing a 4.2
release at all. For example:
[Option 1] Instead of 4.2, we should backport some functionality from
4.2 to the 4.1 branch, and call that 4.2.
[Option 2]
On Mon, 19 Feb 2007, Joe Buck wrote:
> On Tue, Feb 20, 2007 at 12:27:42AM +, Joseph S. Myers wrote:
> >... *All* releases seem to have the
> > predictions that they are useless, should be skipped because the next
> > release will be so much better in way X or Y, etc.; I think the question
> >
Richard Guenther napisał(a):
On 2/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll have a 4.2.0 release by (worst case, and allowing fo
On 2/20/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll have a 4.2.0 release by (worst case, and allowing for
lameness on my part) March 3
Mark Mitchell wrote:
I've heard various comments about whether or not it's worth doing a 4.2
release at all. For example:
[...]
So, my feeling is that the best course of action is to set a relatively
low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th.
Then, we'll have
Wiadomość napisana w dniu 2007-02-20, o godz01:27, przez Joseph S.
Myers:
This is *not* the only such prediction for a previous release, by far,
just the one I found quickest. *All* releases seem to have the
predictions that they are useless, should be skipped because the next
release will
On Tue, Feb 20, 2007 at 12:27:42AM +, Joseph S. Myers wrote:
>... *All* releases seem to have the
> predictions that they are useless, should be skipped because the next
> release will be so much better in way X or Y, etc.; I think the question
> of how widely used a release series turned o
On Mon, 19 Feb 2007, Mark Mitchell wrote:
> One of the key points behind these suggestions is that Red Hat and
> Novell plan to skip to 4.3 for their next releases, so we'll have a hard
> By hypothesis, 4.1 is satisfactory (shipping with major GNU/Linux
> distributions, and widely used throughou
39 matches
Mail list logo
