GCC version bikeshedding

[Richard Biener]

On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek <jakub@redhat.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 <jakub@redhat.com> 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