This is the mail archive of the
mailing list for the GCC project.
Re: GCC version bikeshedding
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Eric Botcazou <ebotcazou at libertysurf dot fr>, Ian Lance Taylor <iant at google dot com>, GCC Development <gcc at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>
- Date: Wed, 6 Aug 2014 11:04:14 +0200
- Subject: Re: GCC version bikeshedding
- Authentication-results: sourceware.org; auth=none
- References: <20140720165506 dot GT3003 at laptop dot redhat dot com> <201407291845 dot 14107 dot ebotcazou at libertysurf dot fr> <CAKOQZ8whj_m9yjYVdX_p24ocV25VRZwwmTf=VvGjEoxNeHbxSg at mail dot gmail dot com> <201408060925 dot 48414 dot ebotcazou at libertysurf dot fr> <20140806074223 dot GY7393 at tucnak dot redhat dot com> <CAFiYyc1+LTfbPF=nT3O4pA4ST6Z2X5FJ0ywMxL9bk3UsqwnV2w at mail dot gmail dot com> <20140806084803 dot GB7393 at tucnak dot redhat dot com>
On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek <email@example.com> 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 <firstname.lastname@example.org> 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
> - 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
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