Re: Time for GCC 5.0? (TIC)
Marketing loves high numbers after all! If you truly think this way, we're going to have to revoke your hacker's license ;-)
Re: Time for GCC 5.0? (TIC)
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)
On Tue, Nov 6, 2012 at 7:06 AM, Jeff Law l...@redhat.com wrote: On 11/05/2012 07:43 PM, DJ Delorie wrote: Ian Lance Taylor i...@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)
On 11/11/2012 04:47 AM, NightStrike wrote: On Sat, Nov 10, 2012 at 6:20 AM, Andrew Haley a...@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)
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)
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 jos...@codesourcery.com
Re: Time for GCC 5.0? (TIC)
On Sat, Nov 10, 2012 at 6:20 AM, Andrew Haley a...@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)
Il 06/11/2012 03:43, DJ Delorie ha scritto: Ian Lance Taylor i...@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)
On Mon, Nov 5, 2012 at 11:21 PM, Jonathan Wakely jwakely@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)
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)
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)
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 +, 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
Time for GCC 5.0? (TIC)
On Wed, 24 Mar 2010 04:34:15 +, 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)
On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher stevenb@gmail.com wrote: On Wed, 24 Mar 2010 04:34:15 +, 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)
On 2012-11-05 16:17 , Ian Lance Taylor wrote: On Mon, Nov 5, 2012 at 3:45 PM, Steven Bosscher stevenb@gmail.com wrote: On Wed, 24 Mar 2010 04:34:15 +, 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)
Ian Lance Taylor i...@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)
On 11/05/2012 07:43 PM, DJ Delorie wrote: Ian Lance Taylor i...@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
