Time for GCC 5.0? (TIC)

Time for GCC 5.0? (TIC)

[Steven Bosscher]

On Wed, 24 Mar 2010 04:34:15 +0000, Dave Korn wrote:
>
>   Say, why don't we reserve GCC 5.0 for the first version that gets rid of
> reload?  Then let's see if we can get there while the X in 4.X is still in
> single digits!

(see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html)

I suppose LRA counts, even if it doesn't get rid of reload completely just yet.

Bump the number! :-)

Ciao!
Steven

Re: Time for GCC 5.0? (TIC)

[Ian Lance Taylor]

On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
> On Wed, 24 Mar 2010 04:34:15 +0000, Dave Korn wrote:
>>
>>   Say, why don't we reserve GCC 5.0 for the first version that gets rid of
>> reload?  Then let's see if we can get there while the X in 4.X is still in
>> single digits!
>
> (see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html)
>
> I suppose LRA counts, even if it doesn't get rid of reload completely just yet.
>
> Bump the number! :-)

Also the fact that GCC is now written in C++ seems to me to be
deserving of a bump to 5.0.

So now we have two reasons!

Ian

Re: Time for GCC 5.0? (TIC)

[Diego Novillo]

On 2012-11-05 16:17 , Ian Lance Taylor wrote:
> On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher <stevenb.gcc@gmail.com> wrote:
>> On Wed, 24 Mar 2010 04:34:15 +0000, Dave Korn wrote:
>>>
>>>    Say, why don't we reserve GCC 5.0 for the first version that gets rid of
>>> reload?  Then let's see if we can get there while the X in 4.X is still in
>>> single digits!
>>
>> (see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html)
>>
>> I suppose LRA counts, even if it doesn't get rid of reload completely just yet.
>>
>> Bump the number! :-)
>
> Also the fact that GCC is now written in C++ seems to me to be
> deserving of a bump to 5.0.

I agree.  This might be a good time to bump the major version number. 
In addition to the C++ switch, I think we have a ton of new features. 
Alerting users that this release may be a double-edged sword seems wise.


Diego.

Re: Time for GCC 5.0? (TIC)

[DJ Delorie]

Ian Lance Taylor <iant@google.com> writes:
> Also the fact that GCC is now written in C++ seems to me to be
> deserving of a bump to 5.0.

I see no reason why an internal design change that has no user visible
effects should have any impact on the version number.

Typically a major version bump is reserved for either massive new
functionality or a break with backwards compatibility.

Re: Time for GCC 5.0? (TIC)

[Jeff Law]

On 11/05/2012 07:43 PM, DJ Delorie wrote:
>
> Ian Lance Taylor <iant@google.com> writes:
>> Also the fact that GCC is now written in C++ seems to me to be
>> deserving of a bump to 5.0.
>
> I see no reason why an internal design change that has no user visible
> effects should have any impact on the version number.
>
> Typically a major version bump is reserved for either massive new
> functionality or a break with backwards compatibility.
I tend to agree that major version number bumps ought to be tied to 
major user-visible changes.

I think dropping reload would quality, particularly if there are other 
major user visible changes going on.  For example, significant 
improvements in modularity allowing for easier plugin development, major 
improvements in static & dynamic analysis capabilities, etc.

jeff

Re: Time for GCC 5.0? (TIC)

[Florian Weimer]

On 11/06/2012 07:06 AM, Jeff Law wrote:

> I tend to agree that major version number bumps ought to be tied to
> major user-visible changes.
>
> I think dropping reload would quality, particularly if there are other
> major user visible changes going on.  For example, significant
> improvements in modularity allowing for easier plugin development, major
> improvements in static & dynamic analysis capabilities, etc.

Or a new ABI for libstdc++, I guess.

-- 
Florian Weimer / Red Hat Product Security Team

Re: Time for GCC 5.0? (TIC)

[Jonathan Wakely]

On 6 November 2012 09:16, Florian Weimer wrote:
> On 11/06/2012 07:06 AM, Jeff Law wrote:
>
>> I tend to agree that major version number bumps ought to be tied to
>> major user-visible changes.

It wasn't for GCC 4.0, but I'm not suggesting it should be done again.
 The new C++ parser and ABI in GCC 3.4 was a far more visible
difference than SSA.

>> I think dropping reload would quality, particularly if there are other
>> major user visible changes going on.  For example, significant
>> improvements in modularity allowing for easier plugin development, major
>> improvements in static & dynamic analysis capabilities, etc.
>
>
> Or a new ABI for libstdc++, I guess.

Which is not on the cards for the foreseeable future.  The suggested
attributes to allow old and new libstdc++ ABIs to coexist, and
dropping the "experimental" rider from C++11 mode would warrant a
major version bump IMHO.

Re: Time for GCC 5.0? (TIC)

[Steven Bosscher]

On Tue, Nov 6, 2012 at 1:17 AM, Ian Lance Taylor wrote:
> On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher wrote:
>> On Wed, 24 Mar 2010 04:34:15 +0000, Dave Korn wrote:
>>>
>>>   Say, why don't we reserve GCC 5.0 for the first version that gets rid of
>>> reload?  Then let's see if we can get there while the X in 4.X is still in
>>> single digits!
>>
>> (see http://gcc.gnu.org/ml/gcc-patches/2010-03/msg01103.html)
>>
>> I suppose LRA counts, even if it doesn't get rid of reload completely just yet.
>>
>> Bump the number! :-)
>
> Also the fact that GCC is now written in C++ seems to me to be
> deserving of a bump to 5.0.
>
> So now we have two reasons!

A third reason would be the much improved diagnostics, which are
user-visible changes: caret diagnostics, marco expansion, etc. There's
still a lot to do on that front but it's a user visible and quite
significant change.

But the TIC in $SUBJECT was for "tongue in cheek". Spawning a repeat
of the GCC 4.0 discussion wasn't my intention.

Ciao!
Steven

Re: Time for GCC 5.0? (TIC)

[Paolo Bonzini]

Il 06/11/2012 03:43, DJ Delorie ha scritto:
> Ian Lance Taylor <iant@google.com> writes:
>> > Also the fact that GCC is now written in C++ seems to me to be
>> > deserving of a bump to 5.0.
> I see no reason why an internal design change that has no user visible
> effects should have any impact on the version number.

Technically, requiring a C++ compiler to bootstrap is a user visible effect.

Paolo

Re: Time for GCC 5.0? (TIC)

[NightStrike]

On Mon, Nov 5, 2012 at 11:21 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 6 November 2012 09:16, Florian Weimer wrote:
> > On 11/06/2012 07:06 AM, Jeff Law wrote:
> >
> >> I tend to agree that major version number bumps ought to be tied to
> >> major user-visible changes.

> > Or a new ABI for libstdc++, I guess.

> Which is not on the cards for the foreseeable future.  The suggested
> attributes to allow old and new libstdc++ ABIs to coexist, and
> dropping the "experimental" rider from C++11 mode would warrant a
> major version bump IMHO.

Making c99 the default for gcc would be a great candidate for this.
IIUC, gcc without -std=c99 will compile for c89.  And if I read the
manual correctly, it's because c99 isn't finished yet.  gcc 5.0 should
have a complete c99.

Re: Time for GCC 5.0? (TIC)

[Andrew Haley]

On 11/10/2012 04:45 AM, NightStrike wrote:
> Making c99 the default for gcc would be a great candidate for this.
> IIUC, gcc without -std=c99 will compile for c89.  And if I read the
> manual correctly, it's because c99 isn't finished yet.  gcc 5.0 should
> have a complete c99.

"Should" in what sense?  The missing features are either library issues that
we can't do anything about or things that no-one cares about enough to
fix.  GCC is, to all intents and purposes, C99 compatible.

See http://gcc.gnu.org/c99status.html

Andrew.

Re: Time for GCC 5.0? (TIC)

[Joseph S. Myers]

On Fri, 9 Nov 2012, NightStrike wrote:

> Making c99 the default for gcc would be a great candidate for this.
> IIUC, gcc without -std=c99 will compile for c89.  And if I read the
> manual correctly, it's because c99 isn't finished yet.  gcc 5.0 should
> have a complete c99.

The reason gnu99 is not the default is not that certain corner cases of 
extended identifiers do not work ideally (in particular regarding handling 
of different source-code spellings of the same UCN) and so extended 
identifiers are still in their own option rather than enabled by default 
for C99 and C++, it's that there is no warning option to warn about 
C90/C99 incompatibilities when compiling in gnu99 mode to at least the 
extent -pedantic diagnoses things when compiling in gnu89 mode.  Given 
such a warning option I think it would be reasonable to make gnu99 the 
default.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Time for GCC 5.0? (TIC)

[NightStrike]

On Sat, Nov 10, 2012 at 6:20 AM, Andrew Haley <aph@redhat.com> wrote:
> On 11/10/2012 04:45 AM, NightStrike wrote:
>> Making c99 the default for gcc would be a great candidate for this.
>> IIUC, gcc without -std=c99 will compile for c89.  And if I read the
>> manual correctly, it's because c99 isn't finished yet.  gcc 5.0 should
>> have a complete c99.
>
> "Should" in what sense?  The missing features are either library issues that
> we can't do anything about or things that no-one cares about enough to
> fix.  GCC is, to all intents and purposes, C99 compatible.
>
> See http://gcc.gnu.org/c99status.html

The manual doesn't imply that:

"-std=gnu99 GNU dialect of ISO C99. When ISO C99 is fully implemented
in GCC, this will become the default."

So from the perspective of the user reading the manual entry for the
gnu99 option, the only feedback is 1) c99 isn't done, and 2) there's
some plan to finish it and then make it the default.

You seem to imply that it's as done as it'll ever realistically be.

Sounds kind of conflicting.

Re: Time for GCC 5.0? (TIC)

[Andrew Haley]

On 11/11/2012 04:47 AM, NightStrike wrote:
> On Sat, Nov 10, 2012 at 6:20 AM, Andrew Haley <aph@redhat.com> wrote:
>> On 11/10/2012 04:45 AM, NightStrike wrote:
>>> Making c99 the default for gcc would be a great candidate for this.
>>> IIUC, gcc without -std=c99 will compile for c89.  And if I read the
>>> manual correctly, it's because c99 isn't finished yet.  gcc 5.0 should
>>> have a complete c99.
>>
>> "Should" in what sense?  The missing features are either library issues that
>> we can't do anything about or things that no-one cares about enough to
>> fix.  GCC is, to all intents and purposes, C99 compatible.
>>
>> See http://gcc.gnu.org/c99status.html
> 
> The manual doesn't imply that:
> 
> "-std=gnu99 GNU dialect of ISO C99. When ISO C99 is fully implemented
> in GCC, this will become the default."
> 
> So from the perspective of the user reading the manual entry for the
> gnu99 option, the only feedback is 1) c99 isn't done, and 2) there's
> some plan to finish it and then make it the default.
>
> You seem to imply that it's as done as it'll ever realistically be.

I can't possibly know that: someone might decide to do the last bit of
work to be able to claim full compatibility.  Nonetheless, I agree
with Joseph's opinion that it would be reasonable to make gnu99 the
default.

> Sounds kind of conflicting.

I think the statement in the manual is a bit idealistic.

Andrew.

Re: Time for GCC 5.0? (TIC)

[Georg-Johann Lay]

DJ Delorie schrieb:
> Ian Lance Taylor writes:
>> Also the fact that GCC is now written in C++ seems to me to be
>> deserving of a bump to 5.0.
> 
> I see no reason why an internal design change that has no user visible
> effects should have any impact on the version number.

Changing the implementation language is not an internal change.  GCC is 
a source project.  Anyone who takes the sources and who wants to roll a 
distribution or just wants to compile GCC, will need a C++ compiler now.

Thus, it's a major change for these "first-level" users.

Johann

> Typically a major version bump is reserved for either massive new
> functionality or a break with backwards compatibility.

Re: Time for GCC 5.0? (TIC)

[Richard Biener]

On Tue, Nov 6, 2012 at 7:06 AM, Jeff Law <law@redhat.com> wrote:
> On 11/05/2012 07:43 PM, DJ Delorie wrote:
>>
>>
>> Ian Lance Taylor <iant@google.com> writes:
>>>
>>> Also the fact that GCC is now written in C++ seems to me to be
>>> deserving of a bump to 5.0.
>>
>>
>> I see no reason why an internal design change that has no user visible
>> effects should have any impact on the version number.
>>
>> Typically a major version bump is reserved for either massive new
>> functionality or a break with backwards compatibility.
>
> I tend to agree that major version number bumps ought to be tied to major
> user-visible changes.
>
> I think dropping reload would quality, particularly if there are other major
> user visible changes going on.  For example, significant improvements in
> modularity allowing for easier plugin development, major improvements in
> static & dynamic analysis capabilities, etc.

I'd rather make version numbers "simpler" by dropping one sub-part.
Thus 4.8.0 would become 5.0 (and branch releases 5.1, 5.2, etc.) and
4.9.0 would then be 6.0.  Marketing loves high numbers after all!

Richard.

> jeff

Re: Time for GCC 5.0? (TIC)

[DJ Delorie]

> Marketing loves high numbers after all!

If you truly think this way, we're going to have to revoke your hacker's license ;-)