On Tue, 23 Jan 2007, Diego Novillo wrote:
There was some discussion on IRC that I would like to move to the
mailing list so that we get a wider discussion. There's been thoughts
about skipping 4.2 completely, or going to an extended Stage 3, etc.
Thoughts?
I believe that going forward we sho
Mark Mitchell wrote on 01/25/07 00:09:
First, I haven't had as much time to put in as RM lately as in past, so
I haven't been nagging people as much.
>
Sure, but this is a trend that started with 3.1 and it's gotten
progressively worse. Granted, we are now dealing with a much bigger
project
On 1/25/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > >Gcc 4.2 has a serious FP performace issue:
> > >
> > >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
> > >
> > >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
> > >wi
On 1/25/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
> >Gcc 4.2 has a serious FP performace issue:
> >
> >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
> >
> >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
> >will be addressed.
>
> As always, the best way to ensure that it is a
On Thu, Jan 25, 2007 at 09:57:45AM -0500, Robert Dewar wrote:
> H. J. Lu wrote:
>
> >Gcc 4.2 has a serious FP performace issue:
> >
> >http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
> >
> >on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
> >will be addressed.
>
> As always, t
H. J. Lu wrote:
Gcc 4.2 has a serious FP performace issue:
http://gcc.gnu.org/ml/gcc/2007-01/msg00408.html
on both ia32 and x86-64. If there will be a 4.2.0 release, I hope it
will be addressed.
As always, the best way to ensure that it is addressed if it is
important to you is to address it
On Thu, Jan 25, 2007 at 11:18:34AM +0100, François-Xavier Coudert wrote:
> [sorry for breaking the thread; stupid gmail doesn't want to add
> custom References headers]
>
> >It may be that not too many people pick up 4.2.0. But, if 4.3 isn't
> >looking very stable, there will be a point when peop
[sorry for breaking the thread; stupid gmail doesn't want to add
custom References headers]
It may be that not too many people pick up 4.2.0. But, if 4.3 isn't
looking very stable, there will be a point when people decide that 4.2.0
is looking very attractive. The worst outcome of trying to do
Diego Novillo wrote:
> So, I was doing some archeology on past releases and we seem to be
> getting into longer release cycles. With 4.2 we have already crossed
> the 1 year barrier.
I think there are several factors here.
First, I haven't had as much time to put in as RM lately as in past, so
Marcin Dalecki wrote:
Wiadomość napisana w dniu 2007-01-24, o godz23:52, przez Mike Stump:
On Jan 24, 2007, at 1:12 PM, Marcin Dalecki wrote:
It could be a starting point to help avoiding quite a lot of
overhead needed to iterate over command line options for example.
Odd. You think that time
Wiadomość napisana w dniu 2007-01-24, o godz23:52, przez Mike Stump:
On Jan 24, 2007, at 1:12 PM, Marcin Dalecki wrote:
One thing that would certainly help as a foundation for possible
further improvement in performance in this area would be to have
xgcc contain all the front ends directly
Wiadomość napisana w dniu 2007-01-24, o godz23:26, przez Andrew
Pinski:
On Wed, 24 Jan 2007 03:02:19 +0100, Marcin Dalecki
<[EMAIL PROTECTED]> said:
That's largely because individual tests in the test suite are too
long, which in turn is because the tests are testing code at a
per-binar
On Wed, 24 Jan 2007 17:26:32 -0500 (EST), Andrew Pinski
<[EMAIL PROTECTED]> said:
>> That's largely because individual tests in the test suite are too
>> long, which in turn is because the tests are testing code at a
>> per-binary granularity: you have to run all of gcc, or all of one
>> of the pr
On Jan 24, 2007, at 1:12 PM, Marcin Dalecki wrote:
One thing that would certainly help as a foundation for possible
further improvement in performance in this area would be to have
xgcc contain all the front ends directly linked into it.
That does seem debatable.
It could be a starting poin
>
> On Wed, 24 Jan 2007 03:02:19 +0100, Marcin Dalecki <[EMAIL PROTECTED]> said:
>
> That's largely because individual tests in the test suite are too
> long, which in turn is because the tests are testing code at a
> per-binary granularity: you have to run all of gcc, or all of one
> of the prog
Wiadomość napisana w dniu 2007-01-24, o godz19:53, przez Mike Stump:
On Jan 23, 2007, at 11:03 PM, Marcin Dalecki wrote:
That's just about a quarter million lines of code to process and
you think the infrastructure around it isn't crap on the order of
100?
Standard answer, trivially, it i
On Wed, 24 Jan 2007 11:12:24 +0200, Michael Veksler <[EMAIL PROTECTED]> said:
> Deterministic unit-tests are almost useless in long lived projects,
I think you might be using the term "unit test" differently from me?
Nothing is more valuable for a long-lived project than having unit
tests coverin
On Tue, 23 Jan 2007 23:16:47 -0500 (EST), Andrew Pinski <[EMAIL PROTECTED]>
said:
> Let me bring up another point:
> 0) bugs go unnoticed for a couple of releases and then become part of
> the release criteria.
Yeah, that's a good point. So maybe there's another feedback loop to
consider:
lon
On Wed, 24 Jan 2007 03:02:19 +0100, Marcin Dalecki <[EMAIL PROTECTED]> said:
> Wiadomość napisana w dniu 2007-01-24, o godz02:30, przez David Carlton:
>> For 4, you should probably spend some time figuring out why bugs are
>> being introduced into the code in the first place. Is test coverage
>>
> "Marcin" == Marcin Dalecki <[EMAIL PROTECTED]> writes:
Marcin> Just forget ADA and Java in mainstream. Both of them are seriously
Marcin> impeding casual contributions.
We tried this once for libgcj. We had gcj in the tree (small amount
of code, couldn't really bother anybody) but not libg
On Jan 24, 2007, at 11:08 AM, Marcin Dalecki wrote:
This argument fails (trivially) on the assumption that there is an
incremental way ("fixes") to improve it in time not exceeding the
expected remaining life span of a developer.
I welcome your existence proof for just one piece that can't b
Wiadomość napisana w dniu 2007-01-24, o godz19:53, przez Mike Stump:
On Jan 23, 2007, at 11:03 PM, Marcin Dalecki wrote:
That's just about a quarter million lines of code to process and
you think the infrastructure around it isn't crap on the order of
100?
Standard answer, trivially, it i
On Jan 23, 2007, at 11:03 PM, Marcin Dalecki wrote:
That's just about a quarter million lines of code to process and you
think the infrastructure around it isn't crap on the order of 100?
Standard answer, trivially, it is as good as you want it to be. If
you wanted it to be better, you'd co
Wiadomość napisana w dniu 2007-01-24, o godz14:05, przez Michael
Veksler:
From my experience on my small constraint solver (80,000 LOC) by
making stuff
more suitable for random unit testing you get:
1. Maintainable+reusable code (with all its benefits).
2. Faster code: Due to simplici
Marcin Dalecki wrote:
Wiadomość napisana w dniu 2007-01-24, o godz10:12, przez Michael Veksler:
Andrew, you are both correct and incorrect. Certainly, deterministic
unit testing
is not very useful. However, random unit testing is priceless. I have
been doing
pseudo-random unit tests for years,
On 1/24/07, David Carlton <[EMAIL PROTECTED]> wrote:
On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo <[EMAIL PROTECTED]> said:
> So, I was doing some archeology on past releases and we seem to be
> getting into longer release cycles.
Interesting.
I'm a GCC observer, not a participant, but he
Wiadomość napisana w dniu 2007-01-24, o godz10:12, przez Michael
Veksler:
Andrew, you are both correct and incorrect. Certainly,
deterministic unit testing
is not very useful. However, random unit testing is priceless. I
have been doing
pseudo-random unit tests for years, believe me it
Andrew Pinski wrote:
My guess is that most or all of those are factors, but some are more
important than others. My favorite tactic to decrease the number of
bugs is to set up a unit test framework for your code base (so you can
test changes to individual functions without having to run the whol
Wiadomość napisana w dniu 2007-01-24, o godz04:32, przez Andrew Pinski:
It's "too good" to be usable. The time required for a full test suite
run can be measured by days not hours.
Days, only for slow machines. For our PS3 toolchain (which is really
two sperate compilers), it takes 6 hours
Marcin Dalecki wrote:
A trivial by nature change like the
top level build of libgcc took actually years to come by.
I'm not sure how much that's inherently evidence that it was
inappropriately difficult to do, though.
For example, the quite trivial change of having "make pdf" support for
cr
>
> On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo <[EMAIL PROTECTED]> said:
>
> > So, I was doing some archeology on past releases and we seem to be
> > getting into longer release cycles.
>
> Interesting.
>
> I'm a GCC observer, not a participant, but here are some thoughts:
>
> As far as
>
>
> Wiadomo¶æ napisana w dniu 2007-01-24, o godz02:30, przez David Carlton:
>
> > For 4, you should probably spend some time figuring out why bugs are
> > being introduced into the code in the first place. Is test coverage
> > not good enough?
The test coverage is not good for C++ while it i
Wiadomość napisana w dniu 2007-01-24, o godz02:30, przez David Carlton:
For 4, you should probably spend some time figuring out why bugs are
being introduced into the code in the first place. Is test coverage
not good enough?
It's "too good" to be usable. The time required for a full test su
On Tue, 23 Jan 2007 17:54:10 -0500, Diego Novillo <[EMAIL PROTECTED]> said:
> So, I was doing some archeology on past releases and we seem to be
> getting into longer release cycles.
Interesting.
I'm a GCC observer, not a participant, but here are some thoughts:
As far as I can tell, it looks t
Wiadomość napisana w dniu 2007-01-24, o godz01:48, przez David Daney:
I missed the discussion on IRC, but neither of those front-ends are
release blockers.
I cannot speak for ADA, but I am not aware that the Java front-end
has caused any release delays recently. I am sure you will correct
Marcin Dalecki wrote:
Wiadomość napisana w dniu 2007-01-23, o godz23:54, przez Diego Novillo:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already crossed
the 1 year barrier.
For 4.3 we have already added quite a
On Wed, Jan 24, 2007 at 12:55:29AM +0100, Steven Bosscher wrote:
> On 1/23/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> >
> >So, I was doing some archeology on past releases and we seem to be
> >getting into longer release cycles. With 4.2 we have already crossed
> >the 1 year barrier.
>
> Heh.
Wiadomość napisana w dniu 2007-01-23, o godz23:54, przez Diego Novillo:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already
crossed the 1 year barrier.
For 4.3 we have already added quite a bit of infrastructure
On 1/23/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already crossed
the 1 year barrier.
Heh.
Maybe part of the problem here is that the release manager isn't very
actively
So, I was doing some archeology on past releases and we seem to be
getting into longer release cycles. With 4.2 we have already crossed
the 1 year barrier.
For 4.3 we have already added quite a bit of infrastructure that is all
good in paper but still needs some amount of TLC.
There was s
40 matches
Mail list logo
