Re: Backporting Patches to GCC 7
On Mon, May 8, 2017 at 10:00 PM, Jonathan Wakely wrote: > On 5 May 2017 at 21:35, Palmer Dabbelt wrote: >> I just submitted two patches against trunk. I'd like to also have them on >> the >> 7 branch, so when 7.2 comes out we'll have them. These patches only touch >> the >> RISC-V backend, which I'm a maintainer of. Is there a branch maintainer I'm >> supposed to have sign off on the patches or am I meant to just decide on my >> own >> what I should commit? >> >> For reference, here's the patches >> >> 284b54c RISC-V: Add -mstrict-align option >> 70218e8 RISC-V: Unify indention in riscv.md > > In general, backports that aren't fixing regressions or documentation > would need release managers approval. There's some leeway for target > maintainers of ports and other subsystems, for example I sometimes > make executive decisions about the C++ runtime libraries when the > backport only affects an isolated part of the library, or is clearly > safe and an obvious improvement. For bigger changes that aren't > regressions but I'd like to backport I still seek RM approval. > > I would guess that for RISC-V which is new in 7.1, if you think the > backport is important and it doesn't affect other targets then it > should be OK. > > Maybe one of the release managers can confirm that though. Generally all maintainers can also approve backports. Richard.
Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates
On 05/09/2017 01:36 AM, Daniel Santos wrote: To further the usefulness of such techniques, I propose the addition of a c-family attribute to declare a parameter, variable (and possibly other declarations) as "constprop" or some similar word. The purpose of the attribute is to: 1.) Emit a warning or error when the value is not optimized away, and 2.) Direct various optimization passes to prefer (or force) either cloning or inlining of a function with such a parameter. I think GCC used to treat C and C++ constant expressions this way in the old days. That is, what was a constant expression depended to some degree on the capabilities of the folder at least (and maybe the optimizers). This wasn't such a great idea because it made behavior inconsistent across architectures and GCC versions. There are also thorny specification issues, like is an array whose length is a constprop value a VLA or not? If you are interested in metaprogramming techniques, you are probably better off writing code generators or using a C++ subset. Thanks, Florian
Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates
On Tuesday 09 May 2017, Daniel Santos wrote: > The primary aim is to facilitate high-performance generic C > libraries for software where C++ is not suitable, but the cost of > run-time abstraction is unacceptable. A good example is the Linux > kernel, where the source tree is littered with more than 100 hand-coded > or boiler-plate (copy, paste and edit) search cores required to use the > red-black tree library. That is not a good excuse, they can just use a defined subset of C++. The cost of C++ abstractions is zero if you don't use them. > > To further the usefulness of such techniques, I propose the addition of > a c-family attribute to declare a parameter, variable (and possibly > other declarations) as "constprop" or some similar word. The purpose of > the attribute is to: > > 1.) Emit a warning or error when the value is not optimized away, and > 2.) Direct various optimization passes to prefer (or force) either > cloning or inlining of a function with such a parameter. > This I can get more behind, I have wanted a constexpr attribute for C for some time. If not for anything else to be able to use it in shared/system headers that can be used by both C and C++ and in C++ would be useful in constexpr expressions. If you can find a use for it in pure C as well, so much the better. `Allan
gcc-5-20170509 is now available
Snapshot gcc-5-20170509 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170509/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 247819 You'll find: gcc-5-20170509.tar.bz2 Complete GCC SHA256=d89ef59f24dbe900a952c5fb7079610c4cac2b09aaca9f8c95e4e90ffe7ad7f9 SHA1=22dcd950057583119bd82adb1809385d8f497703 Diffs from 5-20170502 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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.
Move myself to Write After Approval section
Hi all, I am stepping down as the SH backend maintainer for personal reasons. I might still send tiny SH patches and sh-linux testresults if the HDD of my SH machine can be recovered. I've moved myself to write after approval section. I didn't think that I could be involved with such huge and highly sophisticated software when I sent my first awful patch. It was full of fun to participate in this great community. I've learned what is the right thing and how it can be done on the list. Thanks to all members of gcc community! Best Regards, kaz -- 2017-05-09 Kaz Kojima * MAINTAINERS: Move myself to Write After Approval section. Index: MAINTAINERS === --- MAINTAINERS (revision 247819) +++ MAINTAINERS (working copy) @@ -101,7 +101,6 @@ s390 port Andreas Krebbel score port Chen Liqin sh portAlexandre Oliva -sh portKaz Kojima sh portOleg Endo sparc port Richard Henderson sparc port David S. Miller @@ -449,6 +448,7 @@ Jeff Knaggs Michael Koch Nicolas Koenig +Kaz Kojima Dave Korn Matt Kraai Jan Kratochvil
Re: Backporting Patches to GCC 7
On Tue, 09 May 2017 01:50:42 PDT (-0700), richard.guent...@gmail.com wrote: > On Mon, May 8, 2017 at 10:00 PM, Jonathan Wakely > wrote: >> On 5 May 2017 at 21:35, Palmer Dabbelt wrote: >>> I just submitted two patches against trunk. I'd like to also have them on >>> the >>> 7 branch, so when 7.2 comes out we'll have them. These patches only touch >>> the >>> RISC-V backend, which I'm a maintainer of. Is there a branch maintainer I'm >>> supposed to have sign off on the patches or am I meant to just decide on my >>> own >>> what I should commit? >>> >>> For reference, here's the patches >>> >>> 284b54c RISC-V: Add -mstrict-align option >>> 70218e8 RISC-V: Unify indention in riscv.md >> >> In general, backports that aren't fixing regressions or documentation >> would need release managers approval. There's some leeway for target >> maintainers of ports and other subsystems, for example I sometimes >> make executive decisions about the C++ runtime libraries when the >> backport only affects an isolated part of the library, or is clearly >> safe and an obvious improvement. For bigger changes that aren't >> regressions but I'd like to backport I still seek RM approval. >> >> I would guess that for RISC-V which is new in 7.1, if you think the >> backport is important and it doesn't affect other targets then it >> should be OK. >> >> Maybe one of the release managers can confirm that though. > > Generally all maintainers can also approve backports. OK, thanks. Since the RISC-V port is so new I'd like to be a bit aggressive about backporting our fixes. If this goes anything like binutils did, there's going to be a handful of bug fixes that trickle in over the next few weeks as more people start using the port now that there's a release. For example, we've got a few patches in the pipeline that get our -mcmodel=medany working passing the test suite. Is it OK if I pretty much just backport everything RISC-V related to gcc-7-branch, as long as it doesn't touch any other port? I can ping you about each patch if you'd like.
