* Moving to C++11
@ 2019-09-30 17:50 Nicholas Krause
2019-10-15 17:00 ` PING:Re: " Nicholas Krause
0 siblings, 1 reply; 12+ messages in thread
From: Nicholas Krause @ 2019-09-30 17:50 UTC (permalink / raw)
To: Jason Merrill, Jonathan Wakely; +Cc: gcc Mailing List
Greetings Jonathan and Jason,
I was wondering what work is required to move to C++11. Seems your
both interested in getting this done and so am I. Perhaps we start
similar to Git with a wiki page about what features would be useful
and then start migrating the makefiles to allow for this.
So far according to the previous discussion it seems that the community
would like these features:
1. Template Aliases
2. Better narrowing supprot for core types
2. Auto for local variables
3. std::move,rvalues
4. For each loops
Let me know if I missed something but I will be glad to help out with this,
Nick
^ permalink raw reply [flat|nested] 12+ messages in thread
* PING:Re: Moving to C++11
2019-09-30 17:50 Moving to C++11 Nicholas Krause
@ 2019-10-15 17:00 ` Nicholas Krause
0 siblings, 0 replies; 12+ messages in thread
From: Nicholas Krause @ 2019-10-15 17:00 UTC (permalink / raw)
To: Jason Merrill, Jonathan Wakely; +Cc: gcc Mailing List
On 9/30/19 1:50 PM, Nicholas Krause wrote:
> Greetings Jonathan and Jason,
>
> I was wondering what work is required to move to C++11. Seems your
>
> both interested in getting this done and so am I. Perhaps we start
>
> similar to Git with a wiki page about what features would be useful
>
> and then start migrating the makefiles to allow for this.
>
> So far according to the previous discussion it seems that the community
>
> would like these features:
>
> 1. Template Aliases
>
> 2. Better narrowing supprot for core types
>
> 2. Auto for local variables
>
> 3. std::move,rvalues
>
> 4. For each loops
>
> Let me know if I missed something but I will be glad to help out with
> this,
>
> Nick
>
> Just pinging this as I've not heard any replies.
Nick
^ permalink raw reply [flat|nested] 12+ messages in thread
* Moving to C++11
@ 2019-09-29 22:57 Nicholas Krause
0 siblings, 0 replies; 12+ messages in thread
From: Nicholas Krause @ 2019-09-29 22:57 UTC (permalink / raw)
To: David Edelsohn; +Cc: gcc Mailing List
Greetings David,
I posted on the list about moving to C++11/C11 but the focus was on
C++11 for my work. Seems that other people wanted to use some
parts of the C++11 standard including rvalues,move,auto and template
aliases. The thread is here:
https://gcc.gnu.org/ml/gcc/2019-09/msg00228.html
I've come to the conclusion that enabling parts of it would be useful
overall based
on the linked discussion.
Therefore I'm opening up the discussion again with the commitee involved
to figure
out what should be used and how the migration should take place,
Nick
^ permalink raw reply [flat|nested] 12+ messages in thread
* Moving to C++11
@ 2019-09-26 4:10 Nicholas Krause
2019-09-26 7:23 ` Jonathan Wakely
2019-09-27 0:17 ` Eric Gallager
0 siblings, 2 replies; 12+ messages in thread
From: Nicholas Krause @ 2019-09-26 4:10 UTC (permalink / raw)
To: gcc Mailing List
Greetings,
I asked about moving to C/C++ 11 as it would make it easier to
allow multithreading support due to having a memory model
alongside other features. Jason Merill mentioned due to it
being so common it may be a good time to.
Moving to git seems to be universally agree on so I'm opening the discussion
for the same as related to C/C++11 migration and if possible opening
a TODO similar to git if decided on.
Please post your comments or ideas about the migration in response to this
email,
Nick
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Moving to C++11
2019-09-26 4:10 Nicholas Krause
@ 2019-09-26 7:23 ` Jonathan Wakely
2019-09-26 8:08 ` Richard Biener
2019-09-27 0:17 ` Eric Gallager
1 sibling, 1 reply; 12+ messages in thread
From: Jonathan Wakely @ 2019-09-26 7:23 UTC (permalink / raw)
To: nick; +Cc: gcc Mailing List
On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <xerofoify@gmail.com> wrote:
>
> Greetings,
>
> I asked about moving to C/C++ 11 as it would make it easier to
>
> allow multithreading support due to having a memory model
>
> alongside other features. Jason Merill mentioned due to it
>
> being so common it may be a good time to.
>
> Moving to git seems to be universally agree on so I'm opening the discussion
>
> for the same as related to C/C++11 migration and if possible opening
>
> a TODO similar to git if decided on.
>
> Please post your comments or ideas about the migration in response to this
>
> email,
For a start, it doesn't make sense to talk about C/C++11.
C and C++ are separate languages, and so are C11 and C++11. There is
no reason why using C++11 should imply using C11, let's not confuse
things.
GCC is written in C++ so the topic should be C++11.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Moving to C++11
2019-09-26 7:23 ` Jonathan Wakely
@ 2019-09-26 8:08 ` Richard Biener
2019-09-26 16:30 ` Nicholas Krause
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Richard Biener @ 2019-09-26 8:08 UTC (permalink / raw)
To: Jonathan Wakely; +Cc: nick, gcc Mailing List
On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <xerofoify@gmail.com> wrote:
> >
> > Greetings,
> >
> > I asked about moving to C/C++ 11 as it would make it easier to
> >
> > allow multithreading support due to having a memory model
> >
> > alongside other features. Jason Merill mentioned due to it
> >
> > being so common it may be a good time to.
> >
> > Moving to git seems to be universally agree on so I'm opening the discussion
> >
> > for the same as related to C/C++11 migration and if possible opening
> >
> > a TODO similar to git if decided on.
> >
> > Please post your comments or ideas about the migration in response to this
> >
> > email,
>
>
>
> For a start, it doesn't make sense to talk about C/C++11.
>
> C and C++ are separate languages, and so are C11 and C++11. There is
> no reason why using C++11 should imply using C11, let's not confuse
> things.
>
> GCC is written in C++ so the topic should be C++11.
Note the main issue is host compiler support. I'm not sure if C++11 would
be the step we'd gain most - for some hashtable issues I'd have needed
std::move support for example. There's always the possibility to
require an intermediate step (first build GCC 5, with that you can build
trunk, etc.), a install.texi clarification could be useful here (or even
some automation via a contrib/ script).
I'm not too worried about requiring even a C++14 compiler, for the
set of products we still release latest compilers we have newer
GCCs available we can use for building them (even if those are
not our primary supported compilers which would limit us to
GCC 4.8).
Note I'd still not like to see more C++ feature creep into general
non-container/infrastructure code, C++ is complex enough as-is.
Richard.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Moving to C++11
2019-09-26 8:08 ` Richard Biener
@ 2019-09-26 16:30 ` Nicholas Krause
2019-09-26 17:27 ` Jason Merrill
2019-09-26 23:03 ` Pedro Alves
2 siblings, 0 replies; 12+ messages in thread
From: Nicholas Krause @ 2019-09-26 16:30 UTC (permalink / raw)
To: Richard Biener; +Cc: Jonathan Wakely, gcc Mailing List
On 9/26/19 4:08 AM, Richard Biener wrote:
> On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <xerofoify@gmail.com> wrote:
>>> Greetings,
>>>
>>> I asked about moving to C/C++ 11 as it would make it easier to
>>>
>>> allow multithreading support due to having a memory model
>>>
>>> alongside other features. Jason Merill mentioned due to it
>>>
>>> being so common it may be a good time to.
>>>
>>> Moving to git seems to be universally agree on so I'm opening the discussion
>>>
>>> for the same as related to C/C++11 migration and if possible opening
>>>
>>> a TODO similar to git if decided on.
>>>
>>> Please post your comments or ideas about the migration in response to this
>>>
>>> email,
>>
>>
>> For a start, it doesn't make sense to talk about C/C++11.
>>
>> C and C++ are separate languages, and so are C11 and C++11. There is
>> no reason why using C++11 should imply using C11, let's not confuse
>> things.
>>
>> GCC is written in C++ so the topic should be C++11.
> Note the main issue is host compiler support. I'm not sure if C++11 would
> be the step we'd gain most - for some hashtable issues I'd have needed
> std::move support for example. There's always the possibility to
> require an intermediate step (first build GCC 5, with that you can build
> trunk, etc.), a install.texi clarification could be useful here (or even
> some automation via a contrib/ script).
I agree.
>
> I'm not too worried about requiring even a C++14 compiler, for the
> set of products we still release latest compilers we have newer
> GCCs available we can use for building them (even if those are
> not our primary supported compilers which would limit us to
> GCC 4.8).
> Note I'd still not like to see more C++ feature creep into general
> non-container/infrastructure code, C++ is complex enough as-is.
While the features that seem to be the most useful to use I will
list below:
1. C++ memory model and atomics classes
2. Move and R values
3. Auto?
4. For each loops may be nice i.e. x: array loops through all of the array
To your point it seems that the above are the most useful and we can
just avoid the others as these don't really affect core code and even
if they do its an extension rather of older features. Auto is just
templates for variables really.
Nick
>
> Richard.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Moving to C++11
2019-09-26 8:08 ` Richard Biener
2019-09-26 16:30 ` Nicholas Krause
@ 2019-09-26 17:27 ` Jason Merrill
2019-09-26 17:54 ` Tom Tromey
2019-09-26 23:03 ` Pedro Alves
2 siblings, 1 reply; 12+ messages in thread
From: Jason Merrill @ 2019-09-26 17:27 UTC (permalink / raw)
To: Richard Biener; +Cc: Jonathan Wakely, nick, gcc Mailing List
On Thu, Sep 26, 2019 at 4:08 AM Richard Biener
<richard.guenther@gmail.com> wrote:
> On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> > On Thu, 26 Sep 2019, 05:10 Nicholas Krause, <xerofoify@gmail.com> wrote:
> > >
> > > Greetings,
> > >
> > > I asked about moving to C/C++ 11 as it would make it easier to
> > >
> > > allow multithreading support due to having a memory model
> > >
> > > alongside other features. Jason Merill mentioned due to it
> > >
> > > being so common it may be a good time to.
> > >
> > > Moving to git seems to be universally agree on so I'm opening the discussion
> > >
> > > for the same as related to C/C++11 migration and if possible opening
> > >
> > > a TODO similar to git if decided on.
> > >
> > > Please post your comments or ideas about the migration in response to this
> > >
> > > email,
> >
> >
> >
> > For a start, it doesn't make sense to talk about C/C++11.
> >
> > C and C++ are separate languages, and so are C11 and C++11. There is
> > no reason why using C++11 should imply using C11, let's not confuse
> > things.
> >
> > GCC is written in C++ so the topic should be C++11.
>
> Note the main issue is host compiler support. I'm not sure if C++11 would
> be the step we'd gain most - for some hashtable issues I'd have needed
> std::move support for example. There's always the possibility to
> require an intermediate step (first build GCC 5, with that you can build
> trunk, etc.), a install.texi clarification could be useful here (or even
> some automation via a contrib/ script).
Note that std::move is from C++11.
> I'm not too worried about requiring even a C++14 compiler, for the
> set of products we still release latest compilers we have newer
> GCCs available we can use for building them (even if those are
> not our primary supported compilers which would limit us to
> GCC 4.8).
I wouldn't object to C++14, but there's nothing in there I
particularly want to use, so it seems unnecessary.
> Note I'd still not like to see more C++ feature creep into general
> non-container/infrastructure code, C++ is complex enough as-is.
I agree for rvalue references. I want to start using C++11 'auto' in
local variable declarations.
Jason
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Moving to C++11
2019-09-26 17:27 ` Jason Merrill
@ 2019-09-26 17:54 ` Tom Tromey
2019-09-26 18:32 ` Richard Sandiford
0 siblings, 1 reply; 12+ messages in thread
From: Tom Tromey @ 2019-09-26 17:54 UTC (permalink / raw)
To: Jason Merrill; +Cc: Richard Biener, Jonathan Wakely, nick, gcc Mailing List
>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
Jason> Note that std::move is from C++11.
>> I'm not too worried about requiring even a C++14 compiler, for the
>> set of products we still release latest compilers we have newer
>> GCCs available we can use for building them (even if those are
>> not our primary supported compilers which would limit us to
>> GCC 4.8).
Jason> I wouldn't object to C++14, but there's nothing in there I
Jason> particularly want to use, so it seems unnecessary.
>> Note I'd still not like to see more C++ feature creep into general
>> non-container/infrastructure code, C++ is complex enough as-is.
Jason> I agree for rvalue references. I want to start using C++11 'auto' in
Jason> local variable declarations.
FWIW in gdb we went with C++11, because it was the version that offered
the most useful upgrades -- for me those was mainly move and foreach,
but 'auto' is sometimes nice as well.
Tom
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Moving to C++11
2019-09-26 17:54 ` Tom Tromey
@ 2019-09-26 18:32 ` Richard Sandiford
0 siblings, 0 replies; 12+ messages in thread
From: Richard Sandiford @ 2019-09-26 18:32 UTC (permalink / raw)
To: Tom Tromey
Cc: Jason Merrill, Richard Biener, Jonathan Wakely, nick, gcc Mailing List
Tom Tromey <tom@tromey.com> writes:
>>>>>> "Jason" == Jason Merrill <jason@redhat.com> writes:
>
> Jason> Note that std::move is from C++11.
>
>>> I'm not too worried about requiring even a C++14 compiler, for the
>>> set of products we still release latest compilers we have newer
>>> GCCs available we can use for building them (even if those are
>>> not our primary supported compilers which would limit us to
>>> GCC 4.8).
>
> Jason> I wouldn't object to C++14, but there's nothing in there I
> Jason> particularly want to use, so it seems unnecessary.
>
>>> Note I'd still not like to see more C++ feature creep into general
>>> non-container/infrastructure code, C++ is complex enough as-is.
>
> Jason> I agree for rvalue references. I want to start using C++11 'auto' in
> Jason> local variable declarations.
>
> FWIW in gdb we went with C++11, because it was the version that offered
> the most useful upgrades -- for me those was mainly move and foreach,
> but 'auto' is sometimes nice as well.
FWIW, on top of what's already been mentioned:
- "= default" would be very useful for some of the core types
- explicit conversion operators would avoid dangerous implicit conversions
to things like bool. E.g. it should be safe to provide an explicit
operator bool() for poly_int and avoid those pesky known_eq (..., 0)/
maybe_ne (..., 0) conditions
- templated type aliases would simplify wide_int
Richard
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Moving to C++11
2019-09-26 8:08 ` Richard Biener
2019-09-26 16:30 ` Nicholas Krause
2019-09-26 17:27 ` Jason Merrill
@ 2019-09-26 23:03 ` Pedro Alves
2 siblings, 0 replies; 12+ messages in thread
From: Pedro Alves @ 2019-09-26 23:03 UTC (permalink / raw)
To: Richard Biener, Jonathan Wakely; +Cc: nick, gcc Mailing List
On 9/26/19 9:08 AM, Richard Biener wrote:
> Note the main issue is host compiler support. I'm not sure if C++11 would
> be the step we'd gain most - for some hashtable issues I'd have needed
> std::move support for example. There's always the possibility to
> require an intermediate step (first build GCC 5, with that you can build
> trunk, etc.), a install.texi clarification could be useful here (or even
> some automation via a contrib/ script).
>
> I'm not too worried about requiring even a C++14 compiler, for the
> set of products we still release latest compilers we have newer
> GCCs available we can use for building them (even if those are
> not our primary supported compilers which would limit us to
> GCC 4.8).
FWIW, GDB requires C++11 nowadays, and the baseline required
GCC version is GCC 4.8.1. The current policy is here:
https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
Pasted for convenience:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When is GDB going to start requiring C++NN ?
Our general policy is to wait until the oldest compiler that
supports C++NN is at least 3 years old.
Rationale: We want to ensure reasonably widespread compiler
availability, to lower barrier of entry to GDB contributions,
and to make it easy for users to easily build new GDB on currently
supported stable distributions themselves. 3 years should be sufficient
for latest stable releases of distributions to include a compiler
for the standard, and/or for new compilers to appear as easily
installable optional packages. Requiring everyone to build a compiler
first before building GDB, which would happen if we required a
too-new compiler, would cause too much inconvenience.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
That was decided 3 years ago, so I guess we'd be good for a
reevaluation, though I don't particularly miss C++14 features
all that much, so I wouldn't mind staying with C++11 for a while
longer in GDB. But if GCC jumps to C++14, I think GDB would
follow along. Just FYI.
C++03 -> C++11 makes a great difference. Particularly
std::move and rvalue references are a game changer.
Thanks,
Pedro Alves
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Moving to C++11
2019-09-26 4:10 Nicholas Krause
2019-09-26 7:23 ` Jonathan Wakely
@ 2019-09-27 0:17 ` Eric Gallager
1 sibling, 0 replies; 12+ messages in thread
From: Eric Gallager @ 2019-09-27 0:17 UTC (permalink / raw)
To: Nicholas Krause; +Cc: gcc Mailing List
On 9/26/19, Nicholas Krause <xerofoify@gmail.com> wrote:
> Greetings,
>
> I asked about moving to C/C++ 11 as it would make it easier to
>
> allow multithreading support due to having a memory model
>
> alongside other features. Jason Merill mentioned due to it
>
> being so common it may be a good time to.
>
> Moving to git seems to be universally agree on so I'm opening the
> discussion
>
> for the same as related to C/C++11 migration and if possible opening
>
> a TODO similar to git if decided on.
>
> Please post your comments or ideas about the migration in response to this
>
> email,
>
> Nick
>
>
A good first step would be to flip the switch from -Wno-narrowing to
-Wnarrowing in the warning flags GCC uses when building, as C++11 has
stricter rules about narrowing conversions. This would be useful even
if we don't end up going to C++11 yet, as such narrowing conversions
are bad even in versions of the standard where they're allowed.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-10-15 17:00 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-30 17:50 Moving to C++11 Nicholas Krause
2019-10-15 17:00 ` PING:Re: " Nicholas Krause
-- strict thread matches above, loose matches on Subject: below --
2019-09-29 22:57 Nicholas Krause
2019-09-26 4:10 Nicholas Krause
2019-09-26 7:23 ` Jonathan Wakely
2019-09-26 8:08 ` Richard Biener
2019-09-26 16:30 ` Nicholas Krause
2019-09-26 17:27 ` Jason Merrill
2019-09-26 17:54 ` Tom Tromey
2019-09-26 18:32 ` Richard Sandiford
2019-09-26 23:03 ` Pedro Alves
2019-09-27 0:17 ` Eric Gallager
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).