On Sun, Aug 24, 2014 at 12:43 PM, Gerald Pfeifer wrote:
> On Sun, 20 Jul 2014, Geert Bosch wrote:
>> 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
On Sun, 20 Jul 2014, Geert Bosch wrote:
> 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...
I did not see a response to t
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
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 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 i
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 r
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
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 compar
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 ad
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
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:
> > - li
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 wan
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,
>>
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
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 ne
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 wit
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 wo
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
> 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 effor
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 bu
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 bu
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?
>> >>
>> >> P
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 accel
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
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. Thi
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
> 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
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
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
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 r
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 shoul
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 feature
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
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'
> 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 de
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 nex
> 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
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
th
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 v
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.
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.
>>
>>> Give
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
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.
Andrea
> 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
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 = 58
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 th
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
>> >>> brea
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.
>>
>> Look
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 id
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 vers
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 ve
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 worthwhil
> 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 a
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 =
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
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
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
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 j
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
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
>>
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
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 re
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-m
> 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
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
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 potentiall
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 1C
> -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:
> >
>
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
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 ~ Apri
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
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
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
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
74 matches
Mail list logo
