Kyrylo Tkachov and Richard Sandiford appointed AArch64 maintainers.
Hi, I'm pleased to announce that the GCC steering committee has appointed Kyrylo Tkachov and Richard Sandiford as AArch64 maintainers. Please join me in congratulating them both on their additional roles in the community. Kyrill / Richard, please update your listings in the MAINTAINERS file. Thanks, Ramana
Re: Moving to C++11
On Thu, 26 Sep 2019, 05:10 Nicholas Krause, 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.
Re: Moving to C++11
On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely wrote: > > On Thu, 26 Sep 2019, 05:10 Nicholas Krause, 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.
Re: Kyrylo Tkachov and Richard Sandiford appointed AArch64 maintainers.
On 9/26/19 8:02 AM, Ramana Radhakrishnan wrote: Hi, I'm pleased to announce that the GCC steering committee has appointed Kyrylo Tkachov and Richard Sandiford as AArch64 maintainers. Please join me in congratulating them both on their additional roles in the community. Kyrill / Richard, please update your listings in the MAINTAINERS file. Thanks! Committed the attached with r276142. Kyrill 2019-09-26 Kyrylo Tkachov * MAINTAINERS: Add myself as aarch64 maintainer. Thanks, Ramana diff --git a/MAINTAINERS b/MAINTAINERS index 948d56d8346ba2df42142955910d4e8a74f568e5..4bbedb4e5c06ac341abc0e2be3720376893a17f4 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -46,6 +46,7 @@ docs, and the testsuite related to that. aarch64 port Richard Earnshaw aarch64 port James Greenhalgh aarch64 port Marcus Shawcroft +aarch64 port Kyrylo Tkachov aarch64 SVE port Richard Sandiford alpha port Richard Henderson amdgcn port Julian Brown
Re: Kyrylo Tkachov and Richard Sandiford appointed AArch64 maintainers.
Kyrill Tkachov writes: > On 9/26/19 8:02 AM, Ramana Radhakrishnan wrote: >> Hi, >> >> I'm pleased to announce that the GCC steering committee has appointed >> Kyrylo Tkachov and Richard Sandiford as AArch64 maintainers. >> >> Please join me in congratulating them both on their additional roles >> in the community. Kyrill / Richard, please update your listings in the >> MAINTAINERS file. >> > Thanks! +1 Committed as follows (keeping alphabetical ordering, in case the placement looks weird). Richard 2019-09-26 Richard Sandiford * MAINTAINERS: Add myself as an aarch64 maintainer. Index: MAINTAINERS === --- MAINTAINERS 2019-09-26 11:42:31.838492675 +0100 +++ MAINTAINERS 2019-09-26 11:54:27.037286003 +0100 @@ -45,9 +45,9 @@ docs, and the testsuite related to that. aarch64 port Richard Earnshaw aarch64 port James Greenhalgh +aarch64 port Richard Sandiford aarch64 port Marcus Shawcroft aarch64 port Kyrylo Tkachov -aarch64 SVE port Richard Sandiford alpha port Richard Henderson amdgcn portJulian Brown amdgcn portAndrew Stubbs
Re: GCC Git hooks
> But before I say more I should point to the documentation which, > for historical reasons, is available on the GDB wiki rather than > the git-hooks GitHub repository. I will fix that, but in the meantime: > > https://sourceware.org/gdb/wiki/GitHooksUsersGuide Just a quick note to confirm that the documentation has now been moved to the git-hooks github page: https://github.com/adacore/git-hooks Don't hesitate to reach out to me, if you have questions, or would like some help configuring the hooks. -- Joel
Re: Reposurgeon status
On 9/25/19 2:32 PM, Eric S. Raymond wrote: > Since the subject of repository conversions has come up, a situation report... > > I am in the very last stages of qualifying the Go port of reposurgeon. > Most importantly to your project, the Go code passed all of the > existing regression tests for reading Subversion stream dumps two days > ago. That is a big deal, as the stream dump reader was by *far* the > trickiest and most bug-prone part to translate. [ ... ] > > I think I'm looking at somewhere between 7 and 14 days until I can start > work on the GCC move again. Getting to this point has taken a year. [ ... ] Good to hear there's been major progress. Probably the most important thing to know is the project will make a decision on Dec 16 to choose the conversion tool. The evaluation is based on the state of tool's conversion on that date. More details: > https://gcc.gnu.org/wiki/GitConversion You should consider the dates in there as firm. You might want to update the state of reposurgeon on that page. Jeff
Re: Moving to C++11
On 9/26/19 4:08 AM, Richard Biener wrote: On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely wrote: On Thu, 26 Sep 2019, 05:10 Nicholas Krause, 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.
Re: Moving to C++11
On Thu, Sep 26, 2019 at 4:08 AM Richard Biener wrote: > On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely wrote: > > On Thu, 26 Sep 2019, 05:10 Nicholas Krause, 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
Re: Moving to C++11
> "Jason" == Jason Merrill 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
Re: Reposurgeon status
Jeff Law : > Probably the most important thing to know is the project will make a > decision on Dec 16 to choose the conversion tool. The evaluation is > based on the state of tool's conversion on that date. More details: > > > https://gcc.gnu.org/wiki/GitConversion > > You should consider the dates in there as firm. I think it is extremely likely that I will have a final conversion ready by then. The only known problem that is in any way serious is the x-bit propagation bug, and I may already have fixed that. I'd think I'd have to get blindsided by something much larger to miss that deadline. > You might want to update the state of reposurgeon on that page. I will do so. -- http://www.catb.org/~esr/";>Eric S. Raymond
Re: Moving to C++11
Tom Tromey writes: >> "Jason" == Jason Merrill 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
Re: Reposurgeon status
On Thu, 26 Sep 2019, Eric S. Raymond wrote: > > You might want to update the state of reposurgeon on that page. > > I will do so. Note that once you've created an account, someone will need to add it to the EditorGroup page before you can edit. -- Joseph S. Myers jos...@codesourcery.com
Re: Reposurgeon status
Joseph Myers : > On Thu, 26 Sep 2019, Eric S. Raymond wrote: > > > > You might want to update the state of reposurgeon on that page. > > > > I will do so. > > Note that once you've created an account, someone will need to add it to > the EditorGroup page before you can edit. I'm having trouble with basic account creation, actually. It's to all appearances not accepting the password I set up. I have sent a reset request. -- http://www.catb.org/~esr/";>Eric S. Raymond
gcc-7-20190926 is now available
Snapshot gcc-7-20190926 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190926/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 276168 You'll find: gcc-7-20190926.tar.xzComplete GCC SHA256=e1b55fa288f7bd0f60e1207c4fda0b7ae00dec6e8ba1c36a6451f9dbb3e6e1ff SHA1=5a42d00b8ff1b67b0f94a3a5a14020bdb45a0b20 Diffs from 7-20190919 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Moving to C++11
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
Re: Moving to C++11
On 9/26/19, Nicholas Krause 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.
