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