Re: GCC version bikeshedding
On 08/06/14 04:50, Marc Glisse wrote: A clean .so.7 break would be significantly worse nightmare. We've been there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly fewer C++ plugins etc. in packages and it still it was unsolvable. With the abi_tag stuff, you have the option to make stuff interoperable when mixing compiler, either with no effort at all, or some limited effort. With .so.7, you have no option, nothing will be interoperable. I disagree that it is worse, but you have more experience, I guess we will see the results in a few years... Based on real world end user/developer discussions I've had on this topic over the last few years, a SOname bump would catastrophic. They've made it painfully clear that a SOname bump would be the worst thing that has happened in GCC-land in many years, possibly ever. jeff
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 12:33:42PM +0100, Joern Rennecke wrote:
> On 6 August 2014 11:31, Richard Biener wrote:
> > Ok, so the problematical case is
> >
> > struct X { std::string s; };
> > void foo (X&);
>
> Wouldn't it be even more troublesome with an application that dynloads
> dsos depending on user input.
> The install script might check if the dso with the right soname is present,
> but then you still get dynamic linker errors when the user tries to
> do something with the application, which could be an arbitrary time after
> the upgrade.
Now, if you do the same with libstdc++.so.7, you have exactly the same issue
(need to think what you do with SONAMEs of libraries built with C++), but
furthermore whenever you get both libstdc++.so.6 and libstdc++.so.7 loaded
into the same process, most probably nothing will work at all, there will be
no mangling differences between so.6 and so.7 symbols, etc.
Jakub
Re: GCC version bikeshedding
On 6 August 2014 11:31, Richard Biener wrote:
> Ok, so the problematical case is
>
> struct X { std::string s; };
> void foo (X&);
Wouldn't it be even more troublesome with an application that dynloads
dsos depending on user input.
The install script might check if the dso with the right soname is present,
but then you still get dynamic linker errors when the user tries to
do something with the application, which could be an arbitrary time after
the upgrade.
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 12:50 PM, Marc Glisse wrote:
> On Wed, 6 Aug 2014, Jakub Jelinek wrote:
>
>> On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
>>>
>>> Ok, so the problematical case is
>>>
>>> struct X { std::string s; };
>>> void foo (X&);
>>
>>
>> Yeah.
>>
>>> then. OTOH I remember that then mangling of X changes as well?
>>
>>
>> Only if you add abi_tag attribute to X.
>
>
> Note that -Wabi-tag can tell you where it is needed.
>
> struct __attribute__((abi_tag("marc"))) X {};
> struct Y { X x; };
>
> a.cc:2:8: warning: 'Y' does not have the "marc" abi tag that 'X' (used in
> the type of 'Y::x') has [-Wabi-tag]
> struct Y { X x; };
> ^
> a.cc:2:14: note: 'Y::x' declared here
> struct Y { X x; };
> ^
> a.cc:1:41: note: 'X' declared here
> struct __attribute__((abi_tag("marc"))) X {};
>
> ^
>
>> I hope the libstdc++ folks will add some macro which will
>> include the right abi_tag attribute for the std::list/std::string
>> cases, so you'd in the end just add
>> #ifndef _GLIBCXX_ABI_TAG_SOMETHING
>> #define _GLIBCXX_ABI_TAG_SOMETHING
>> #endif
>> ...
>> struct X _GLIBCXX_ABI_TAG_SOMETHING { std::string s; };
>> void foo (X&);
>> or similar.
>
>
> So we only need to patch every project out there...
I wonder if the linker could not do the propagation for us ...
(ok, it needs to rewrite all symbols and typeinfos, etc., but
certainly doable, no?)
That said, if the public API merely has a forward declaration
class X;
and always passes that by reference the ABI doesn't change.
Of course it now _would_ change if you'd change the mangling
of X ...
abigail to the rescue?
>> A clean .so.7 break would be significantly worse nightmare. We've been
>> there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly
>> fewer C++ plugins etc. in packages and it still it was unsolvable.
>> With the abi_tag stuff, you have the option to make stuff interoperable
>> when mixing compiler, either with no effort at all, or some limited
>> effort. With .so.7, you have no option, nothing will be interoperable.
>
>
> I disagree that it is worse, but you have more experience, I guess we
> will see the results in a few years...
Indeed.
Richard.
> --
> Marc Glisse
Re: GCC version bikeshedding
On Wed, 6 Aug 2014, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
Ok, so the problematical case is
struct X { std::string s; };
void foo (X&);
Yeah.
then. OTOH I remember that then mangling of X changes as well?
Only if you add abi_tag attribute to X.
Note that -Wabi-tag can tell you where it is needed.
struct __attribute__((abi_tag("marc"))) X {};
struct Y { X x; };
a.cc:2:8: warning: 'Y' does not have the "marc" abi tag that 'X' (used in
the type of 'Y::x') has [-Wabi-tag]
struct Y { X x; };
^
a.cc:2:14: note: 'Y::x' declared here
struct Y { X x; };
^
a.cc:1:41: note: 'X' declared here
struct __attribute__((abi_tag("marc"))) X {};
^
I hope the libstdc++ folks will add some macro which will
include the right abi_tag attribute for the std::list/std::string
cases, so you'd in the end just add
#ifndef _GLIBCXX_ABI_TAG_SOMETHING
#define _GLIBCXX_ABI_TAG_SOMETHING
#endif
...
struct X _GLIBCXX_ABI_TAG_SOMETHING { std::string s; };
void foo (X&);
or similar.
So we only need to patch every project out there...
A clean .so.7 break would be significantly worse nightmare. We've been
there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly
fewer C++ plugins etc. in packages and it still it was unsolvable.
With the abi_tag stuff, you have the option to make stuff interoperable
when mixing compiler, either with no effort at all, or some limited
effort. With .so.7, you have no option, nothing will be interoperable.
I disagree that it is worse, but you have more experience, I guess we
will see the results in a few years...
--
Marc Glisse
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 12:35:02PM +0200, Marc Glisse wrote: > >>>It's an ABI change for all modes (but not a SONAME change because the > >>>old and new definitions will both be present in the .so). > >> > >>Ugh. That's going to be a nightmare to support. > > Yes. And IMO a waste of effort compared to a clean .so.7 break, but well... A clean .so.7 break would be significantly worse nightmare. We've been there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly fewer C++ plugins etc. in packages and it still it was unsolvable. With the abi_tag stuff, you have the option to make stuff interoperable when mixing compiler, either with no effort at all, or some limited effort. With .so.7, you have no option, nothing will be interoperable. Jakub
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
> Ok, so the problematical case is
>
> struct X { std::string s; };
> void foo (X&);
Yeah.
> then. OTOH I remember that then mangling of X changes as well?
Only if you add abi_tag attribute to X.
I hope the libstdc++ folks will add some macro which will
include the right abi_tag attribute for the std::list/std::string
cases, so you'd in the end just add
#ifndef _GLIBCXX_ABI_TAG_SOMETHING
#define _GLIBCXX_ABI_TAG_SOMETHING
#endif
...
struct X _GLIBCXX_ABI_TAG_SOMETHING { std::string s; };
void foo (X&);
or similar.
Jakub
Re: GCC version bikeshedding
On Wed, 6 Aug 2014, Richard Biener wrote: It's an ABI change for all modes (but not a SONAME change because the old and new definitions will both be present in the .so). Ugh. That's going to be a nightmare to support. Yes. And IMO a waste of effort compared to a clean .so.7 break, but well... Is there a configure switch to change the default ABI used? That is, on a legacy system can I upgrate to 5.0 and get code that interoperates fine with code built with 4.8? (including ABI boundaries using the affected classes? I suspect APIs with std::string passing are _very_ common, not sure about std::list) What's the failure mode the user will see when linking against a 4.8 compiled library with a std::string interface using 5.0? In good cases, a linker error about a missing symbol (different mangling). In less good cases, a warning at compile-time about using a class marked with abi_tag in a class not marked with it. In worse cases (passing through void* for instance), a runtime crash. And how do libraries with such an API avoid silently changing their ABI dependent on the compiler used to compile them? That is, I suppose those need to change their SONAME dependent on the compiler version used?! Yes, just like a move to .so.7 would entail. -- Marc Glisse
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 12:25 PM, Jonathan Wakely wrote:
> On 6 August 2014 11:20, Richard Biener wrote:
>> On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely
>> wrote:
>>> On 6 August 2014 10:06, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
> > - libstdc++ ABI changes (it is a significant user visible change,
> > if you rebuild everything, no extra effort is needed, but otherwise
> > if you want some C++ code built with older compilers work together
> > with code built with newer compilers, it might require source code
> > changes (the abi_tag attribute additions where needed and warning
> > suggest to put those at), at least that is my current understanding
> > of the plans
>
> But that's only with -std=c++11? Which had no compatibility
> guarantees before?
No, AFAIK it is also -std=c++98. At least my understanding was that
std::list and std::string are going to change ABI (and get new abi_tag)
in all C++ modes. Jonathan/Jason/Paolo, is that right?
>>>
>>> Correct. We want C++03 code to continue to be able to interoperate
>>> with C++11 code.
>>>
>>> It's an ABI change for all modes (but not a SONAME change because the
>>> old and new definitions will both be present in the .so).
>>
>> Ugh. That's going to be a nightmare to support. Is there a configure
>> switch to change the default ABI used?
>
> You'll need to define a macro to get the old versions of the affected
> classes, we can add a configure switch to make that the default.
>
>> That is, on a legacy system
>> can I upgrate to 5.0 and get code that interoperates fine with code
>> built with 4.8? (including ABI boundaries using the affected classes?
>> I suspect APIs with std::string passing are _very_ common, not
>> sure about std::list)
>>
>> What's the failure mode the user will see when linking against a
>> 4.8 compiled library with a std::string interface using 5.0?
>
> There will be a linker error as the types and the interface functions
> will have different mangled names.
Ok, so the problematical case is
struct X { std::string s; };
void foo (X&);
then. OTOH I remember that then mangling of X changes as well?
Is there a documented way to build a shared library with both
variants? Or isn't there a good way to automate that? Like
building the library objects twice once with the new and once
with the old ABI and then simply link both into the shared library?
(of course that doesn't work - but maybe use -ffunction-sections
-fdata-sections and then use the union of all sections discarding
duplicates?)
Richard.
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 12:20:04PM +0200, Richard Biener wrote: > >> No, AFAIK it is also -std=c++98. At least my understanding was that > >> std::list and std::string are going to change ABI (and get new abi_tag) > >> in all C++ modes. Jonathan/Jason/Paolo, is that right? > > > > Correct. We want C++03 code to continue to be able to interoperate > > with C++11 code. > > > > It's an ABI change for all modes (but not a SONAME change because the > > old and new definitions will both be present in the .so). > > Ugh. That's going to be a nightmare to support. Is there a configure > switch to change the default ABI used? That is, on a legacy system > can I upgrate to 5.0 and get code that interoperates fine with code > built with 4.8? (including ABI boundaries using the affected classes? > I suspect APIs with std::string passing are _very_ common, not > sure about std::list) Generally, if you just pass std::string or std::list or & or && or * to it around, things will be just mangled differently, so worst case you'll get linker errors or dynamic linker errors. The problematic case is if you embed std::string or std::list in your classes and pass that around in between projects compiled with one compiler and another compiler, in that case it doesn't affect the mangling, yet is an ABI change nevertheless. In such cases, one needs to add abi_tag to your structures, and there is some g++ warning that can suggest you where to add it. Of course, if you are not using such structures/classes in between packages, it is just fine not to do anything about that. Jakub
Re: GCC version bikeshedding
On 6 August 2014 11:20, Richard Biener wrote: > On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely > wrote: >> On 6 August 2014 10:06, Jakub Jelinek wrote: >>> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: > - libstdc++ ABI changes (it is a significant user visible change, > if you rebuild everything, no extra effort is needed, but otherwise > if you want some C++ code built with older compilers work together > with code built with newer compilers, it might require source code > changes (the abi_tag attribute additions where needed and warning > suggest to put those at), at least that is my current understanding > of the plans But that's only with -std=c++11? Which had no compatibility guarantees before? >>> >>> No, AFAIK it is also -std=c++98. At least my understanding was that >>> std::list and std::string are going to change ABI (and get new abi_tag) >>> in all C++ modes. Jonathan/Jason/Paolo, is that right? >> >> Correct. We want C++03 code to continue to be able to interoperate >> with C++11 code. >> >> It's an ABI change for all modes (but not a SONAME change because the >> old and new definitions will both be present in the .so). > > Ugh. That's going to be a nightmare to support. Is there a configure > switch to change the default ABI used? You'll need to define a macro to get the old versions of the affected classes, we can add a configure switch to make that the default. > That is, on a legacy system > can I upgrate to 5.0 and get code that interoperates fine with code > built with 4.8? (including ABI boundaries using the affected classes? > I suspect APIs with std::string passing are _very_ common, not > sure about std::list) > > What's the failure mode the user will see when linking against a > 4.8 compiled library with a std::string interface using 5.0? There will be a linker error as the types and the interface functions will have different mangled names.
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 12:20 PM, Richard Biener wrote: > On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely > wrote: >> On 6 August 2014 10:06, Jakub Jelinek wrote: >>> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: > - libstdc++ ABI changes (it is a significant user visible change, > if you rebuild everything, no extra effort is needed, but otherwise > if you want some C++ code built with older compilers work together > with code built with newer compilers, it might require source code > changes (the abi_tag attribute additions where needed and warning > suggest to put those at), at least that is my current understanding > of the plans But that's only with -std=c++11? Which had no compatibility guarantees before? >>> >>> No, AFAIK it is also -std=c++98. At least my understanding was that >>> std::list and std::string are going to change ABI (and get new abi_tag) >>> in all C++ modes. Jonathan/Jason/Paolo, is that right? >> >> Correct. We want C++03 code to continue to be able to interoperate >> with C++11 code. >> >> It's an ABI change for all modes (but not a SONAME change because the >> old and new definitions will both be present in the .so). > > Ugh. That's going to be a nightmare to support. Is there a configure > switch to change the default ABI used? That is, on a legacy system > can I upgrate to 5.0 and get code that interoperates fine with code > built with 4.8? (including ABI boundaries using the affected classes? > I suspect APIs with std::string passing are _very_ common, not > sure about std::list) > > What's the failure mode the user will see when linking against a > 4.8 compiled library with a std::string interface using 5.0? And how do libraries with such an API avoid silently changing their ABI dependent on the compiler used to compile them? That is, I suppose those need to change their SONAME dependent on the compiler version used?! Richard. > Thanks, > Richard.
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely wrote: > On 6 August 2014 10:06, Jakub Jelinek wrote: >> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: >>> > - libstdc++ ABI changes (it is a significant user visible change, >>> > if you rebuild everything, no extra effort is needed, but otherwise >>> > if you want some C++ code built with older compilers work together >>> > with code built with newer compilers, it might require source code >>> > changes (the abi_tag attribute additions where needed and warning >>> > suggest to put those at), at least that is my current understanding >>> > of the plans >>> >>> But that's only with -std=c++11? Which had no compatibility >>> guarantees before? >> >> No, AFAIK it is also -std=c++98. At least my understanding was that >> std::list and std::string are going to change ABI (and get new abi_tag) >> in all C++ modes. Jonathan/Jason/Paolo, is that right? > > Correct. We want C++03 code to continue to be able to interoperate > with C++11 code. > > It's an ABI change for all modes (but not a SONAME change because the > old and new definitions will both be present in the .so). Ugh. That's going to be a nightmare to support. Is there a configure switch to change the default ABI used? That is, on a legacy system can I upgrate to 5.0 and get code that interoperates fine with code built with 4.8? (including ABI boundaries using the affected classes? I suspect APIs with std::string passing are _very_ common, not sure about std::list) What's the failure mode the user will see when linking against a 4.8 compiled library with a std::string interface using 5.0? Thanks, Richard.
Re: GCC version bikeshedding
On 6 August 2014 10:06, Jakub Jelinek wrote: > On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: >> > - libstdc++ ABI changes (it is a significant user visible change, >> > if you rebuild everything, no extra effort is needed, but otherwise >> > if you want some C++ code built with older compilers work together >> > with code built with newer compilers, it might require source code >> > changes (the abi_tag attribute additions where needed and warning >> > suggest to put those at), at least that is my current understanding >> > of the plans >> >> But that's only with -std=c++11? Which had no compatibility >> guarantees before? > > No, AFAIK it is also -std=c++98. At least my understanding was that > std::list and std::string are going to change ABI (and get new abi_tag) > in all C++ modes. Jonathan/Jason/Paolo, is that right? Correct. We want C++03 code to continue to be able to interoperate with C++11 code. It's an ABI change for all modes (but not a SONAME change because the old and new definitions will both be present in the .so).
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 11:20:01AM +0200, Marc Glisse wrote: > On Wed, 6 Aug 2014, Jakub Jelinek wrote: > > >- libstdc++ ABI changes > > It seems unlikely to be in the next release, it is too late in the cycle. > Chances to break the ABI don't come often, and rushing one at the end of > stage1 would be wasting a good opportunity. AFAIK it has been planned for two or more years, so I would not say it is rushed. Jakub
Re: GCC version bikeshedding
On Wed, 6 Aug 2014, Jakub Jelinek wrote: - libstdc++ ABI changes It seems unlikely to be in the next release, it is too late in the cycle. Chances to break the ABI don't come often, and rushing one at the end of stage1 would be wasting a good opportunity. -- Marc Glisse
Re: GCC version bikeshedding
> On Aug 6, 2014, at 2:10 AM, Marek Polacek wrote: > >> On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: >>> On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek wrote: >>> - libstdc++ ABI changes (it is a significant user visible change, >>> if you rebuild everything, no extra effort is needed, but otherwise >>> if you want some C++ code built with older compilers work together >>> with code built with newer compilers, it might require source code >>> changes (the abi_tag attribute additions where needed and warning >>> suggest to put those at), at least that is my current understanding >>> of the plans >> >> But that's only with -std=c++11? Which had no compatibility >> guarantees before? >> >>> - likely libgfortran ABI changes (different array descriptors) >> >> Let's wait and see ... >> >> We'll find a good reason to bump the major with every release. >> Like for 4.9 LTO defaults to slim-objects, or C++ rejecting even more >> invalid code, or libstdc++ header re-orgs, or defaulting to dwarf4+ >> (or even support for it), or VTA, or ... >> >> Where do we set the barrier? GCC isn't a C++ (or Fortran) compiler >> only. >> >> So if we change to 5.1 (please not .0) then let's switch the default >> optimization level to -O2! _That's_ a user-visible change across >> the board. > > I'm planning to move the default C standard from gnu90 to gnu11 > (Currently it's blocked on the -Wc90-c99-compat warning). > That's a pretty big user-visible change as well, I suppose. I don't think this is a good move due to extern inline and a lot of code is still k&r c and not even c90. Thanks, Andrew > >Marek
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: > On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek wrote: > > - libstdc++ ABI changes (it is a significant user visible change, > > if you rebuild everything, no extra effort is needed, but otherwise > > if you want some C++ code built with older compilers work together > > with code built with newer compilers, it might require source code > > changes (the abi_tag attribute additions where needed and warning > > suggest to put those at), at least that is my current understanding > > of the plans > > But that's only with -std=c++11? Which had no compatibility > guarantees before? > > > - likely libgfortran ABI changes (different array descriptors) > > Let's wait and see ... > > We'll find a good reason to bump the major with every release. > Like for 4.9 LTO defaults to slim-objects, or C++ rejecting even more > invalid code, or libstdc++ header re-orgs, or defaulting to dwarf4+ > (or even support for it), or VTA, or ... > > Where do we set the barrier? GCC isn't a C++ (or Fortran) compiler > only. > > So if we change to 5.1 (please not .0) then let's switch the default > optimization level to -O2! _That's_ a user-visible change across > the board. I'm planning to move the default C standard from gnu90 to gnu11 (Currently it's blocked on the -Wc90-c99-compat warning). That's a pretty big user-visible change as well, I suppose. Marek
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote: > > - libstdc++ ABI changes (it is a significant user visible change, > > if you rebuild everything, no extra effort is needed, but otherwise > > if you want some C++ code built with older compilers work together > > with code built with newer compilers, it might require source code > > changes (the abi_tag attribute additions where needed and warning > > suggest to put those at), at least that is my current understanding > > of the plans > > But that's only with -std=c++11? Which had no compatibility > guarantees before? No, AFAIK it is also -std=c++98. At least my understanding was that std::list and std::string are going to change ABI (and get new abi_tag) in all C++ modes. Jonathan/Jason/Paolo, is that right? Jakub
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek wrote: > On Wed, Aug 06, 2014 at 10:44:11AM +0200, Richard Biener wrote: >> On Wed, Aug 6, 2014 at 9:42 AM, Jakub Jelinek wrote: >> > On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: >> >> > What do you propose that we do? >> >> >> >> Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. >> > >> > That was my preference too. >> >> What singles out 5.0 to warrant an increase in the major number? >> >> If we don't change then please stay at 4.10, 4.11, 4.12, etc. > > - libstdc++ ABI changes (it is a significant user visible change, > if you rebuild everything, no extra effort is needed, but otherwise > if you want some C++ code built with older compilers work together > with code built with newer compilers, it might require source code > changes (the abi_tag attribute additions where needed and warning > suggest to put those at), at least that is my current understanding > of the plans But that's only with -std=c++11? Which had no compatibility guarantees before? > - likely libgfortran ABI changes (different array descriptors) Let's wait and see ... We'll find a good reason to bump the major with every release. Like for 4.9 LTO defaults to slim-objects, or C++ rejecting even more invalid code, or libstdc++ header re-orgs, or defaulting to dwarf4+ (or even support for it), or VTA, or ... Where do we set the barrier? GCC isn't a C++ (or Fortran) compiler only. So if we change to 5.1 (please not .0) then let's switch the default optimization level to -O2! _That's_ a user-visible change across the board. Richard. > Jakub
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 10:44:11AM +0200, Richard Biener wrote: > On Wed, Aug 6, 2014 at 9:42 AM, Jakub Jelinek wrote: > > On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: > >> > What do you propose that we do? > >> > >> Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. > > > > That was my preference too. > > What singles out 5.0 to warrant an increase in the major number? > > If we don't change then please stay at 4.10, 4.11, 4.12, etc. - libstdc++ ABI changes (it is a significant user visible change, if you rebuild everything, no extra effort is needed, but otherwise if you want some C++ code built with older compilers work together with code built with newer compilers, it might require source code changes (the abi_tag attribute additions where needed and warning suggest to put those at), at least that is my current understanding of the plans - likely libgfortran ABI changes (different array descriptors) Jakub
Re: GCC version bikeshedding
On Wed, Aug 6, 2014 at 9:42 AM, Jakub Jelinek wrote: > On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: >> > What do you propose that we do? >> >> Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. > > That was my preference too. What singles out 5.0 to warrant an increase in the major number? If we don't change then please stay at 4.10, 4.11, 4.12, etc. Richard. > Jakub
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 09:42:23AM +0200, Jakub Jelinek wrote: > On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: > > > What do you propose that we do? > > > > Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. > > That was my preference too. FWIW, me too. This way we'll get in a few years to 10.0 that was also suggested. So please, can we finally settle on something? :) Marek
Re: GCC version bikeshedding
On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote: > > What do you propose that we do? > > Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. That was my preference too. Jakub
Re: GCC version bikeshedding
> What do you propose that we do? Probably just jump to 5.0 (or 5.1) without the subsequent acceleration. > Step 1: We agree that the current major revision number conveys no > information, and therefore we will change the major revision number > with every release. (I understand that you do not agree with this.) Yes. > Step 2: Assuming we agree about step 1, what should the next version > number be? Well, the current version is 4.9. Therefore, the next > version should be 5.0. That seems entirely natural to me. Having the > next release be 10.0 would make no sense to anybody who is not an > active GCC developer. I also disagree with the last assertion (for example Sun did that for Solaris) but that's probably too much bikeshedding at this point. -- Eric Botcazou
Re: GCC version bikeshedding
On Thu, Jul 31, 2014 at 4:22 PM, Ed Smith-Rowland <3dw...@verizon.net> wrote: > On 07/31/2014 07:03 PM, Ian Lance Taylor wrote: >> >> I believe the GCC project has become too large to be able to usefully >> speak about breaking compatibility with previous versions. There are >> too many different moving parts. We break compatibility in various >> minor ways with every release. We try pretty hard to never break >> compatibility in a big way. Historically, as far as I can recall, the >> GCC major release number has never indicated a compatibility break >> that was relevant to most users. >> > What about bumping the default compiler front end versions to C11 or C++11 > or C++14? Even for bootstrap? > There may be some breaking changes that are larger than the usual. C++ is only one of several languages supported by GCC these days. Changing the default C++ version will not affect Fortran, Java, or Ada users. Or, for that matter, C users. Ian
Re: GCC version bikeshedding
On 07/31/2014 07:03 PM, Ian Lance Taylor wrote: On Thu, Jul 31, 2014 at 4:52 AM, NightStrike wrote: One thing you might want to consider is that with the typical X.Y.Z versioning of most GNU projects, changing X allows breaking compatibility in a significant way with previous versions. While Z fixes regressions and Y adds new features, X is a place to make infrequent but paradigm shifting changes that are unconstrained by a desire to stay backwards compatible with older values of X. By going to what is essentially a Y.Z.0 release mechanism, you lose that ability to some degree. Maybe that's ok in a mature project like GCC. I believe the GCC project has become too large to be able to usefully speak about breaking compatibility with previous versions. There are too many different moving parts. We break compatibility in various minor ways with every release. We try pretty hard to never break compatibility in a big way. Historically, as far as I can recall, the GCC major release number has never indicated a compatibility break that was relevant to most users. Ian What about bumping the default compiler front end versions to C11 or C++11 or C++14? Even for bootstrap? There may be some breaking changes that are larger than the usual. FWIW, I do not object to going to 5.0, 6.0. Ed
Re: GCC version bikeshedding
On Tue, Jul 29, 2014 at 9:45 AM, Eric Botcazou wrote: >> I think that if anybody has strong objections, now is the time to make >> them. Otherwise I think we should go with this plan. > > IMHO the cure is worse than the disease. What do you propose that we do? >> Given that there is no clear reason to ever change the major version >> number, making that change will not convey any useful information to >> our users. So let's just drop the major version number. Once we've >> made that decision, then the next release (in 2015) naturally becomes >> 5.0, the release after that (in 2016) becomes 6.0, etc. > > I don't really understand the "naturally": if you drop the major version > number, the next release should be 10.0, not 5.0. Here we seem to be leaning > towards a weird scheme where we retain the major version number but change its > meaning, which will be even more confusing than the current scheme. Step 1: We agree that the current major revision number conveys no information, and therefore we will change the major revision number with every release. (I understand that you do not agree with this.) Step 2: Assuming we agree about step 1, what should the next version number be? Well, the current version is 4.9. Therefore, the next version should be 5.0. That seems entirely natural to me. Having the next release be 10.0 would make no sense to anybody who is not an active GCC developer. Ian
Re: GCC version bikeshedding
On Tue, Jul 29, 2014 at 10:27 AM, Markus Trippelsdorf wrote: > On 2014.07.29 at 19:14 +0200, Richard Biener wrote: >> On July 29, 2014 6:45:13 PM CEST, Eric Botcazou >> wrote: >> >> I think that if anybody has strong objections, now is the time to >> >make >> >> them. Otherwise I think we should go with this plan. >> > >> >IMHO the cure is worse than the disease. >> > >> >> Given that there is no clear reason to ever change the major version >> >> number, making that change will not convey any useful information to >> >> our users. So let's just drop the major version number. Once we've >> >> made that decision, then the next release (in 2015) naturally becomes >> >> 5.0, the release after that (in 2016) becomes 6.0, etc. >> > >> >I don't really understand the "naturally": if you drop the major >> >version >> >number, the next release should be 10.0, not 5.0. >> >> 10.0 would be even better from a marketing perspective. > > Since gcc is released annually why not tie the version to the year of > the release, instead of choosing an arbitrary number? > > 15.o Personally I would prefer that we retain the ability to make more rapid releases. Ian
Re: GCC version bikeshedding
On Thu, Jul 31, 2014 at 4:52 AM, NightStrike wrote: > > One thing you might want to consider is that with the typical X.Y.Z > versioning of most GNU projects, changing X allows breaking > compatibility in a significant way with previous versions. While Z > fixes regressions and Y adds new features, X is a place to make > infrequent but paradigm shifting changes that are unconstrained by a > desire to stay backwards compatible with older values of X. > > By going to what is essentially a Y.Z.0 release mechanism, you lose > that ability to some degree. Maybe that's ok in a mature project like > GCC. I believe the GCC project has become too large to be able to usefully speak about breaking compatibility with previous versions. There are too many different moving parts. We break compatibility in various minor ways with every release. We try pretty hard to never break compatibility in a big way. Historically, as far as I can recall, the GCC major release number has never indicated a compatibility break that was relevant to most users. Ian
Re: GCC version bikeshedding
On Wed, Jul 30, 2014 at 8:00 PM, Jonathan Wakely wrote: > On 30 July 2014 23:18, Eric Botcazou wrote: >>> What are you objecting to, calling the next release from trunk 5.0, >>> and the next one after that 6.0? Or the wording chosen to describe the >>> new versioning scheme? >> >> Let's not start another subthread, please, this will be even more confusing. > > I'm not. I'm trying to get your message back on topic. > >> You can reply to my reply to Ian's message if you deem it necessary. > > Are you objecting to the numbering scheme, or Ian's description of it? > > If you have an objection to the concrete plan it would be nice if you > stated clearly what it is. One thing you might want to consider is that with the typical X.Y.Z versioning of most GNU projects, changing X allows breaking compatibility in a significant way with previous versions. While Z fixes regressions and Y adds new features, X is a place to make infrequent but paradigm shifting changes that are unconstrained by a desire to stay backwards compatible with older values of X. By going to what is essentially a Y.Z.0 release mechanism, you lose that ability to some degree. Maybe that's ok in a mature project like GCC.
Re: GCC version bikeshedding
On 30 July 2014 23:18, Eric Botcazou wrote: >> What are you objecting to, calling the next release from trunk 5.0, >> and the next one after that 6.0? Or the wording chosen to describe the >> new versioning scheme? > > Let's not start another subthread, please, this will be even more confusing. I'm not. I'm trying to get your message back on topic. > You can reply to my reply to Ian's message if you deem it necessary. Are you objecting to the numbering scheme, or Ian's description of it? If you have an objection to the concrete plan it would be nice if you stated clearly what it is.
Re: GCC version bikeshedding
> What are you objecting to, calling the next release from trunk 5.0, > and the next one after that 6.0? Or the wording chosen to describe the > new versioning scheme? Let's not start another subthread, please, this will be even more confusing. You can reply to my reply to Ian's message if you deem it necessary. -- Eric Botcazou
Re: GCC version bikeshedding
On 29 July 2014 21:58, Eric Botcazou wrote: >> How does it change meaning? It's still the major number, just >> incremented more often. > > Reread Ian's post, the original idea is to drop the major version number. I think you're confusing the topic now. What are you objecting to, calling the next release from trunk 5.0, and the next one after that 6.0? Or the wording chosen to describe the new versioning scheme?
Re: GCC version bikeshedding
> How does it change meaning? It's still the major number, just > incremented more often. Reread Ian's post, the original idea is to drop the major version number. -- Eric Botcazou
Re: GCC version bikeshedding
On 29 July 2014 19:29, Joern Rennecke wrote: > E.g. A GCC release on the 1st April 2015 at 09:00 UTC is made > 90 days and 9 hours after the start of the year, and should thus carry > the version number 2015.24760274 P.S.: a patchlevel release in a subsequent year can be marked by increasing the first digit after the decimal point beyond nine into the hexadecimal ream and beyond. So a patchlevel release of gcc 2015.x .on 1st Juy 2018 12:00 UTC would have version number 2015.Y9726027 .
Re: GCC version bikeshedding
On 29 July 2014 18:30, Markus Trippelsdorf wrote: > Since gcc is released annually, why not tie the version to the year of > the release, instead of choosing an arbitrary number? > > 15.o What did the Romans every do for us? Release GCC XV, obviously... Unfortunately, they couldn't release *.0 versions, for lack of a zero. Now, if we are talking about the coming year, that would be 2015. And since we use decimal numbers these days, that should be reflected in version numbers of releases tagged anytime other than 00:00 new years day. A year without leap days/seconds has 365 days of 24 hours of 3600 seconds, so for second accuracy, we need eight digits after the decimal point. E.g. A GCC release on the 1st April 2015 at 09:00 UTC is made 90 days and 9 hours after the start of the year, and should thus carry the version number 2015.24760274
Re: GCC version bikeshedding
On 2014.07.29 at 19:14 +0200, Richard Biener wrote: > On July 29, 2014 6:45:13 PM CEST, Eric Botcazou > wrote: > >> I think that if anybody has strong objections, now is the time to > >make > >> them. Otherwise I think we should go with this plan. > > > >IMHO the cure is worse than the disease. > > > >> Given that there is no clear reason to ever change the major version > >> number, making that change will not convey any useful information to > >> our users. So let's just drop the major version number. Once we've > >> made that decision, then the next release (in 2015) naturally becomes > >> 5.0, the release after that (in 2016) becomes 6.0, etc. > > > >I don't really understand the "naturally": if you drop the major > >version > >number, the next release should be 10.0, not 5.0. > > 10.0 would be even better from a marketing perspective. Since gcc is released annually why not tie the version to the year of the release, instead of choosing an arbitrary number? 15.o -- Markus
Re: GCC version bikeshedding
On 29 July 2014 18:14, Richard Biener wrote: > On July 29, 2014 6:45:13 PM CEST, Eric Botcazou > wrote: >>> I think that if anybody has strong objections, now is the time to >>make >>> them. Otherwise I think we should go with this plan. >> >>IMHO the cure is worse than the disease. >> >>> Given that there is no clear reason to ever change the major version >>> number, making that change will not convey any useful information to >>> our users. So let's just drop the major version number. Once we've >>> made that decision, then the next release (in 2015) naturally becomes >>> 5.0, the release after that (in 2016) becomes 6.0, etc. >> >>I don't really understand the "naturally": if you drop the major >>version >>number, the next release should be 10.0, not 5.0. > > 10.0 would be even better from a marketing perspective. So if we want version number inflation with plausible deniability, how about we first increment the miner version number - so we get 4.10.0, and then we concatenate major and minor version number, yielding 410.0
Re: GCC version bikeshedding
On July 29, 2014 6:45:13 PM CEST, Eric Botcazou wrote: >> I think that if anybody has strong objections, now is the time to >make >> them. Otherwise I think we should go with this plan. > >IMHO the cure is worse than the disease. > >> Given that there is no clear reason to ever change the major version >> number, making that change will not convey any useful information to >> our users. So let's just drop the major version number. Once we've >> made that decision, then the next release (in 2015) naturally becomes >> 5.0, the release after that (in 2016) becomes 6.0, etc. > >I don't really understand the "naturally": if you drop the major >version >number, the next release should be 10.0, not 5.0. 10.0 would be even better from a marketing perspective. Richard. Here we seem to be >leaning >towards a weird scheme where we retain the major version number but >change its >meaning, which will be even more confusing than the current scheme.
Re: GCC version bikeshedding
Eric Botcazou writes: > Here we seem to be leaning towards a weird scheme where we retain the > major version number but change its meaning, which will be even more > confusing than the current scheme. How does it change meaning? It's still the major number, just incremented more often. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC version bikeshedding
> I think that if anybody has strong objections, now is the time to make > them. Otherwise I think we should go with this plan. IMHO the cure is worse than the disease. > Given that there is no clear reason to ever change the major version > number, making that change will not convey any useful information to > our users. So let's just drop the major version number. Once we've > made that decision, then the next release (in 2015) naturally becomes > 5.0, the release after that (in 2016) becomes 6.0, etc. I don't really understand the "naturally": if you drop the major version number, the next release should be 10.0, not 5.0. Here we seem to be leaning towards a weird scheme where we retain the major version number but change its meaning, which will be even more confusing than the current scheme. -- Eric Botcazou
Re: GCC version bikeshedding
Steven Bosscher writes: > Cut the major version number. Solaris 2.9 was marketed as Solaris 9. > Likewise for Solaris 2.10 and 2.11. They simply dropped the 2 from the > version number Which has nothing to do with gcc. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC version bikeshedding
On Sat, Jul 26, 2014 at 7:57 PM, Andreas Schwab wrote: > NightStrike writes: > >> On Jul 26, 2014 9:26 AM, "Andreas Schwab" wrote: >>> >>> pinskia writes: >>> >>> >> On Jul 23, 2014, at 9:51 AM, Andreas Schwab wrote: >>> >> >>> >> Ian Lance Taylor writes: >>> >> >>> >>> At the same time, we face the fact that going from 4.9 to 4.10 will >>> >>> break some people's existing scripts, as is also true of any other >>> >>> decision we can make. >>> >> >>> >> Looking forward to gcc 10.0. :-) >>> > >>> > So are following what sun did? >>> >>> What does this have to do with sun? >>> >> >> It's what sun did for Java and I think Solaris > > Did what? Cut the major version number. Solaris 2.9 was marketed as Solaris 9. Likewise for Solaris 2.10 and 2.11. They simply dropped the 2 from the version number Ciao! Steven
Re: GCC version bikeshedding
NightStrike writes: > On Jul 26, 2014 9:26 AM, "Andreas Schwab" wrote: >> >> pins...@gmail.com writes: >> >> >> On Jul 23, 2014, at 9:51 AM, Andreas Schwab > wrote: >> >> >> >> Ian Lance Taylor writes: >> >> >> >>> At the same time, we face the fact that going from 4.9 to 4.10 will >> >>> break some people's existing scripts, as is also true of any other >> >>> decision we can make. >> >> >> >> Looking forward to gcc 10.0. :-) >> > >> > So are following what sun did? >> >> What does this have to do with sun? >> > > It's what sun did for Java and I think Solaris Did what? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC version bikeshedding
pins...@gmail.com writes: >> On Jul 23, 2014, at 9:51 AM, Andreas Schwab wrote: >> >> Ian Lance Taylor writes: >> >>> At the same time, we face the fact that going from 4.9 to 4.10 will >>> break some people's existing scripts, as is also true of any other >>> decision we can make. >> >> Looking forward to gcc 10.0. :-) > > So are following what sun did? What does this have to do with sun? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC version bikeshedding
On Thu, Jul 24, 2014 at 5:38 PM, Jeff Law wrote: > On 07/23/14 10:20, Ian Lance Taylor wrote: >> >> I am also fine with it. >> >> I think that if anybody has strong objections, now is the time to make >> them. Otherwise I think we should go with this plan. >> >> To me, the basic summary of the idea is that there is no clear reason >> to ever change the GCC major version number. There were real >> objections to changing it when we went from 3 to 4. There will be >> real objections for any future change from 4 to 5. At the same time, >> we face the fact that going from 4.9 to 4.10 will break some people's >> existing scripts, as is also true of any other decision we can make. >> >> Given that there is no clear reason to ever change the major version >> number, making that change will not convey any useful information to >> our users. So let's just drop the major version number. Once we've >> made that decision, then the next release (in 2015) naturally becomes >> 5.0, the release after that (in 2016) becomes 6.0, etc. > > Agreed. It's not 100% perfect, but, IMHO, it's significantly better than > what we're doing now and better than the various alternatives that have been > proposed. If a native speaker can cook something up for the head of gcc-5/changes.html about this change that would be nice. (yes, gcc-5/, not gcc-5.0/ ...) Richard. > Jeff
Re: GCC version bikeshedding
On 07/23/14 10:20, Ian Lance Taylor wrote: I am also fine with it. I think that if anybody has strong objections, now is the time to make them. Otherwise I think we should go with this plan. To me, the basic summary of the idea is that there is no clear reason to ever change the GCC major version number. There were real objections to changing it when we went from 3 to 4. There will be real objections for any future change from 4 to 5. At the same time, we face the fact that going from 4.9 to 4.10 will break some people's existing scripts, as is also true of any other decision we can make. Given that there is no clear reason to ever change the major version number, making that change will not convey any useful information to our users. So let's just drop the major version number. Once we've made that decision, then the next release (in 2015) naturally becomes 5.0, the release after that (in 2016) becomes 6.0, etc. Agreed. It's not 100% perfect, but, IMHO, it's significantly better than what we're doing now and better than the various alternatives that have been proposed. Jeff
Re: GCC version bikeshedding
On Wed, Jul 23, 2014 at 10:00 PM, Jakub Jelinek wrote: > On Wed, Jul 23, 2014 at 09:20:23AM -0700, Ian Lance Taylor wrote: >> I think that if anybody has strong objections, now is the time to make >> them. Otherwise I think we should go with this plan. > > My preference was to keep the current versioning scheme, after all, even > right now it is IMHO worthwhile to tell users about to significant user > visible change with libstdc++ ABI. > But not a strong objection from me. The point is we have significant user visible changes for each release. Where the "significance" is of course a subjective matter. The other thing I could have lived with is doing 4.10.0 (and keeping the major at 4 forever). But "randomly" bumping the major version looks crap to me, esp. as 5.0.0 will be seen as very very experimental. Richard. > Jakub
Re: GCC version bikeshedding
On Wed, Jul 23, 2014 at 09:20:23AM -0700, Ian Lance Taylor wrote: > I think that if anybody has strong objections, now is the time to make > them. Otherwise I think we should go with this plan. My preference was to keep the current versioning scheme, after all, even right now it is IMHO worthwhile to tell users about to significant user visible change with libstdc++ ABI. But not a strong objection from me. Jakub
Re: GCC version bikeshedding
> On Jul 23, 2014, at 9:51 AM, Andreas Schwab wrote: > > Ian Lance Taylor writes: > >> At the same time, we face the fact that going from 4.9 to 4.10 will >> break some people's existing scripts, as is also true of any other >> decision we can make. > > Looking forward to gcc 10.0. :-) So are following what sun did? > > Andreas. > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."
Re: GCC version bikeshedding
Ian Lance Taylor writes: > At the same time, we face the fact that going from 4.9 to 4.10 will > break some people's existing scripts, as is also true of any other > decision we can make. Looking forward to gcc 10.0. :-) Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC version bikeshedding
On Wed, Jul 23, 2014 at 3:28 AM, Jason Merrill wrote: > On 07/20/2014 06:01 PM, Jakub Jelinek wrote: >> >> On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote: >>> >>> I understood we agreed on 5.0 and further 5.1, 5.2 releases from the >>> branch and 6.0 a year later. With unspecified uses for the patch level >>> number (so leave it at zero). >> >> >> Ian/Jason, is that your understanding too? > > > I didn't think that we had come to a decision, but I don't mind going ahead > with this pattern. I am also fine with it. I think that if anybody has strong objections, now is the time to make them. Otherwise I think we should go with this plan. To me, the basic summary of the idea is that there is no clear reason to ever change the GCC major version number. There were real objections to changing it when we went from 3 to 4. There will be real objections for any future change from 4 to 5. At the same time, we face the fact that going from 4.9 to 4.10 will break some people's existing scripts, as is also true of any other decision we can make. Given that there is no clear reason to ever change the major version number, making that change will not convey any useful information to our users. So let's just drop the major version number. Once we've made that decision, then the next release (in 2015) naturally becomes 5.0, the release after that (in 2016) becomes 6.0, etc. Ian
Re: GCC version bikeshedding
On 07/20/2014 06:01 PM, Jakub Jelinek wrote: On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote: I understood we agreed on 5.0 and further 5.1, 5.2 releases from the branch and 6.0 a year later. With unspecified uses for the patch level number (so leave it at zero). Ian/Jason, is that your understanding too? I didn't think that we had come to a decision, but I don't mind going ahead with this pattern. Jason
Re: GCC version bikeshedding
On Wed, Jul 23, 2014 at 4:27 AM, Segher Boessenkool wrote: > On Tue, Jul 22, 2014 at 08:44:41AM +0100, Richard Sandiford wrote: >> So why >> not just stick to the current scheme and have 5.0.0, 5.0.1, 5.0.2 etc.? > > Yes, why would we use a different numbering scheme now? There is no change > in development / release planning, unless I missed something. Is this just > to have bigger number than the "competition"? Or is it change for change's > sake? Are there no more important things to be done? It's to avoid the need to decide whether to bump the major version. For example for the next release I don't see a particularly good reason to bump from 4.9 to 5.0 - not a reason that wasn't present when going from 4.8 to 4.9. And going from 4.9 to 5.0 suggests that 5.0 is not as stable as 4.9 while in reality our "major" version doesn't carry any useful information. Thus, as 4.10.0 is as bad for existing scripts as 5.0.0 take the opportunity to get rid of that no-information-carrying "major" number (by making the patchlevel version unused). And yes, it also looks nicer marketing-wise - but that's not the reason to change it. Richard. > > Segher
Re: GCC version bikeshedding
On Tue, Jul 22, 2014 at 08:44:41AM +0100, Richard Sandiford wrote: > So why > not just stick to the current scheme and have 5.0.0, 5.0.1, 5.0.2 etc.? Yes, why would we use a different numbering scheme now? There is no change in development / release planning, unless I missed something. Is this just to have bigger number than the "competition"? Or is it change for change's sake? Are there no more important things to be done? Segher
Re: GCC version bikeshedding
On Sun, Jul 20, 2014 at 07:01:46PM +0200, Jakub Jelinek wrote: > Ian/Jason, is that your understanding too? In any case, we should mention > it on gcc.gnu.org/index.html, in develop.html and perhaps a few other spots. Also it'd be nice to create htdocs/gcc-5.0/changes.html, so we can start adding new features there. Gerald? Marek
Re: GCC version bikeshedding
On Tue, Jul 22, 2014 at 10:07 AM, Andreas Schwab wrote: > Richard Sandiford writes: > >> Andreas Schwab writes: >>> Richard Sandiford writes: So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions in the number stay the same but the meanings of __GNU_MINOR__ and __GNU_PATCHLEVEL__ change. >>> >>> There is no change in meaning. >> >> Sure there is, in terms of the release progression. The whole point of >> the discussion is that what used to be the "patchlevel" would become >> the "minor version". > > The patchlevel remains the patchlevel, which is the third part of the > version number. It's no longer modified by the offcial releases, but > that doesn't change its meaning. Btw, we'd have the opportunity to fix one long-standing issue with our versioning. Once we release 4.9.1 the branch becomes 4.9.2 (prerelease) but any version checking using __GNU_PATCHLEVEL__ checking for a fix that went into the 4.9.2 release will not work for snapshots between the 4.9.1 and the 4.9.2 releases. Now we'd have the opportunity to encode "prerelease" vs. "" vs. "experimental" with the patchlevel. Say the first release from the branch will be 5.1.0 and immediately after it we bump to 5.1.1 (_not_ 5.2.0 as we do now). For the next release (and a single SVN revision) we bump to 5.2.0 and then immediately to 5.2.1. And we don't have to call it "prerelease" then (which sounds bad, worse than "postrelease" and not changing the version). Richard. > Andreas. > > -- > Andreas Schwab, SUSE Labs, sch...@suse.de > GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 > "And now for something completely different."
Re: GCC version bikeshedding
Richard Sandiford writes: > Andreas Schwab writes: >> Richard Sandiford writes: >>> So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions >>> in the number stay the same but the meanings of __GNU_MINOR__ and >>> __GNU_PATCHLEVEL__ change. >> >> There is no change in meaning. > > Sure there is, in terms of the release progression. The whole point of > the discussion is that what used to be the "patchlevel" would become > the "minor version". The patchlevel remains the patchlevel, which is the third part of the version number. It's no longer modified by the offcial releases, but that doesn't change its meaning. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: GCC version bikeshedding
Andreas Schwab writes: > Richard Sandiford writes: >> So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions >> in the number stay the same but the meanings of __GNU_MINOR__ and >> __GNU_PATCHLEVEL__ change. > > There is no change in meaning. Sure there is, in terms of the release progression. The whole point of the discussion is that what used to be the "patchlevel" would become the "minor version". Richard
Re: GCC version bikeshedding
Richard Sandiford writes: > So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions > in the number stay the same but the meanings of __GNU_MINOR__ and > __GNU_PATCHLEVEL__ change. There is no change in meaning. .. stays the same. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: GCC version bikeshedding
> Was this a Cauldron thing? Could you summarise it for the people who > weren't there? I don't strongly object, but it seems like unnecessary > churn (especially in terms of user expectations). Yeah, bumping the major version number every year is a bit ridiculous. Not as ridiculous as Firefox, but still. -- Eric Botcazou
Re: GCC version bikeshedding
On Mon, Jul 21, 2014 at 10:30 AM, Alec Teal wrote: > Agreed (no experience, but I wouldn't want to live in a world where what > Andi > describes is the case!) We already live in that world. This would not change that. I quite like the proposal. > What is "Bikeshedding"? I've not heard this term before and a quick search > showed > some weird things, and this very thread! Derived from Parkinson's Law of Triviality (http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality). Boils down to giving more weight to trivial aspects of a discussion. Diego.
Re: GCC version bikeshedding
On 20/07/14 22:28, Andi Kleen wrote: Paulo Matos writes: That's what I understood as well. Someone mentioned to leave the patch level number to the distros to use which sounded like a good idea. Sounds like a bad idea, as then there would be non unique gcc versions. redhat gcc 5.0.2 potentially being completely different from suse gcc 5.0.2 Agreed (no experience, but I wouldn't want to live in a world where what Andi describes is the case!) -Andi What is "Bikeshedding"? I've not heard this term before and a quick search showed some weird things, and this very thread! Alec
Re: GCC version bikeshedding
Andi Kleen writes: > Sounds like a bad idea, as then there would be non unique gcc versions. > redhat gcc 5.0.2 potentially being completely different from suse gcc > 5.0.2 How is that different from now? Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
RE: GCC version bikeshedding
> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf > Of Andi Kleen > Sent: 20 July 2014 22:29 > To: Paulo Matos > Cc: gcc@gcc.gnu.org > Subject: Re: GCC version bikeshedding > > Paulo Matos writes: > > > > That's what I understood as well. Someone mentioned to leave the > patch > > level number to the distros to use which sounded like a good idea. > > Sounds like a bad idea, as then there would be non unique gcc > versions. > redhat gcc 5.0.2 potentially being completely different from suse gcc > 5.0.2 > I understand your concern but I am not convinced it's bad. The main reason for this is that we wouldn't distribute GCCs x.y.z with z != 0 so if you would see 5.0.3 in the wild then you could only conclude it's 5.0 with a few patches from some vendor. As I type this I am starting to think how frustrating this might become. However, isn't it the case that nowadays you can have different gcc 4.9.1-2 distributed from different distros? The default gcc in my linode shows: gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) So, I can't see why in the future you couldn't have: Gcc version 5.1 (Ubuntu/Linaro 5.1.3) This is only if the release managers want to assign the patch level number to distros. I don't think there was a decision on this. Paulo Matos
Re: GCC version bikeshedding
Paulo Matos writes: > > That's what I understood as well. Someone mentioned to leave the patch > level number to the distros to use which sounded like a good idea. Sounds like a bad idea, as then there would be non unique gcc versions. redhat gcc 5.0.2 potentially being completely different from suse gcc 5.0.2 -Andi
Re: GCC version bikeshedding
On Jul 20, 2014, at 5:55 PM, Jakub Jelinek wrote: > So, what versioning scheme have we actually agreed on, before I change it in > wwwdocs? Is that > 5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April 2016, > or > 5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ April 2016? > The only thing I understood was that we don't want 4.10, but for the rest > various people expressed different preferences and then it was presented as > agreement on 5.0, which applies to both of the above. Can we use the switch to 5.0, a supposedly stable C++11 ABI etc, also as an excuse to finally configure for --with-sse2 by default for 32-bit x86? Maybe then we can finally retire PR 323 and its dozens of duplicates... -Geert
Re: GCC version bikeshedding
On 20/07/14 17:59, Richard Biener wrote: On July 20, 2014 5:55:06 PM GMT+01:00, Jakub Jelinek wrote: Hi! So, what versioning scheme have we actually agreed on, before I change it in wwwdocs? Is that 5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April 2016, or 5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ April 2016? The only thing I understood was that we don't want 4.10, but for the rest various people expressed different preferences and then it was presented as agreement on 5.0, which applies to both of the above. It is not a big deal either way of course. I understood we agreed on 5.0 and further 5.1, 5.2 releases from the branch and 6.0 a year later. With unspecified uses for the patch level number (so leave it at zero). That's what I understood as well. Someone mentioned to leave the patch level number to the distros to use which sounded like a good idea. Paulo Matos Richard. Jakub
Re: GCC version bikeshedding
On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote: > >So, what versioning scheme have we actually agreed on, before I change > >it in > >wwwdocs? Is that > >5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April > >2016, > >or > >5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ April 2016? > >The only thing I understood was that we don't want 4.10, but for the > >rest > >various people expressed different preferences and then it was > >presented as > >agreement on 5.0, which applies to both of the above. > > > >It is not a big deal either way of course. > > I understood we agreed on 5.0 and further 5.1, 5.2 releases from the > branch and 6.0 a year later. With unspecified uses for the patch level > number (so leave it at zero). Ian/Jason, is that your understanding too? In any case, we should mention it on gcc.gnu.org/index.html, in develop.html and perhaps a few other spots. Jakub
Re: GCC version bikeshedding
On July 20, 2014 5:55:06 PM GMT+01:00, Jakub Jelinek wrote: >Hi! > >So, what versioning scheme have we actually agreed on, before I change >it in >wwwdocs? Is that >5.0.0 in ~ April 2015, 5.0.1 in ~ June-July 2015 and 5.1.0 in ~ April >2016, >or >5.0 in ~ April 2015, 5.1 in ~ June-July 2015 and 6.0 in ~ April 2016? >The only thing I understood was that we don't want 4.10, but for the >rest >various people expressed different preferences and then it was >presented as >agreement on 5.0, which applies to both of the above. > >It is not a big deal either way of course. I understood we agreed on 5.0 and further 5.1, 5.2 releases from the branch and 6.0 a year later. With unspecified uses for the patch level number (so leave it at zero). Richard. > Jakub
