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
On Sun, Aug 24, 2014 at 12:43 PM, Gerald Pfeifer ger...@pfeifer.com 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
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
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 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
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
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
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
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
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
On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek ja...@redhat.com 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
On Aug 6, 2014, at 2:10 AM, Marek Polacek pola...@redhat.com 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 ja...@redhat.com wrote:
- libstdc++ ABI changes (it is a significant user visible change,
if you rebuild
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 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
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
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com 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
On Wed, Aug 6, 2014 at 12:20 PM, Richard Biener
richard.guent...@gmail.com wrote:
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com
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
On 6 August 2014 11:20, Richard Biener wrote:
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com
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 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
On Wed, Aug 6, 2014 at 12:25 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 6 August 2014 11:20, Richard Biener wrote:
On Wed, Aug 6, 2014 at 12:08 PM, Jonathan Wakely jwakely@gmail.com
wrote:
On 6 August 2014 10:06, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 11:04:14AM +0200,
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
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
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
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 6, 2014 at 12:50 PM, Marc Glisse marc.gli...@inria.fr 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
On 6 August 2014 11:31, Richard Biener richard.guent...@gmail.com 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
On Wed, Aug 06, 2014 at 12:33:42PM +0100, Joern Rennecke wrote:
On 6 August 2014 11:31, Richard Biener richard.guent...@gmail.com 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
On Wed, Jul 30, 2014 at 8:00 PM, Jonathan Wakely jwakely@gmail.com 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
On Thu, Jul 31, 2014 at 4:52 AM, NightStrike nightstr...@gmail.com 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
On Tue, Jul 29, 2014 at 10:27 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2014.07.29 at 19:14 +0200, Richard Biener wrote:
On July 29, 2014 6:45:13 PM CEST, Eric Botcazou ebotca...@libertysurf.fr
wrote:
I think that if anybody has strong objections, now is the time to
make
On Tue, Jul 29, 2014 at 9:45 AM, Eric Botcazou ebotca...@libertysurf.fr 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
On 07/31/2014 07:03 PM, Ian Lance Taylor wrote:
On Thu, Jul 31, 2014 at 4:52 AM, NightStrike nightstr...@gmail.com 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
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
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
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 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
Eric Botcazou ebotca...@libertysurf.fr 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
On July 29, 2014 6:45:13 PM CEST, Eric Botcazou ebotca...@libertysurf.fr
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
On 29 July 2014 18:14, Richard Biener richard.guent...@gmail.com wrote:
On July 29, 2014 6:45:13 PM CEST, Eric Botcazou ebotca...@libertysurf.fr
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
On 2014.07.29 at 19:14 +0200, Richard Biener wrote:
On July 29, 2014 6:45:13 PM CEST, Eric Botcazou ebotca...@libertysurf.fr
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
On 29 July 2014 18:30, Markus Trippelsdorf mar...@trippelsdorf.de 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
On 29 July 2014 19:29, Joern Rennecke joern.renne...@embecosm.com 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
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 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
pins...@gmail.com writes:
On Jul 23, 2014, at 9:51 AM, Andreas Schwab sch...@linux-m68k.org wrote:
Ian Lance Taylor i...@google.com 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
NightStrike nightstr...@gmail.com writes:
On Jul 26, 2014 9:26 AM, Andreas Schwab sch...@linux-m68k.org wrote:
pins...@gmail.com writes:
On Jul 23, 2014, at 9:51 AM, Andreas Schwab sch...@linux-m68k.org
wrote:
Ian Lance Taylor i...@google.com writes:
At the same time, we face the
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
Steven Bosscher stevenb@gmail.com 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
On Thu, Jul 24, 2014 at 5:38 PM, Jeff Law l...@redhat.com 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
On Wed, Jul 23, 2014 at 10:00 PM, Jakub Jelinek ja...@redhat.com 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
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
On Wed, Jul 23, 2014 at 4:27 AM, Segher Boessenkool
seg...@kernel.crashing.org 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?
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 3:28 AM, Jason Merrill ja...@redhat.com 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
Ian Lance Taylor i...@google.com 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
On Jul 23, 2014, at 9:51 AM, Andreas Schwab sch...@linux-m68k.org wrote:
Ian Lance Taylor i...@google.com 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
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
Richard Sandiford rdsandif...@googlemail.com 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. MAJOR.MINOR.PATCHLEVEL stays the
same.
Andreas Schwab sch...@linux-m68k.org writes:
Richard Sandiford rdsandif...@googlemail.com 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
Richard Sandiford rdsandif...@googlemail.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Richard Sandiford rdsandif...@googlemail.com 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
On Tue, Jul 22, 2014 at 10:07 AM, Andreas Schwab sch...@linux-m68k.org wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
Andreas Schwab sch...@linux-m68k.org writes:
Richard Sandiford rdsandif...@googlemail.com writes:
So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the
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 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
-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 pa...@matos-sorge.com writes:
That's what I understood
Andi Kleen a...@firstfloor.org 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
On 20/07/14 22:28, Andi Kleen wrote:
Paulo Matospa...@matos-sorge.com 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.
On Mon, Jul 21, 2014 at 10:30 AM, Alec Teal a.t...@warwick.ac.uk 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
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,
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
On July 20, 2014 5:55:06 PM GMT+01:00, Jakub Jelinek ja...@redhat.com 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
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
On 20/07/14 17:59, Richard Biener wrote:
On July 20, 2014 5:55:06 PM GMT+01:00, Jakub Jelinek ja...@redhat.com 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,
On Jul 20, 2014, at 5:55 PM, Jakub Jelinek ja...@redhat.com 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
Paulo Matos pa...@matos-sorge.com 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
74 matches
Mail list logo
