GCC 6 Status Report (2016-01-20), Stage 3 ended
Status == Stage 3 has now officially ended and trunk is in regression and documentation fixes stage now. This means any new features or fixes for bugs that are not regressions have to wait for GCC 7 now. Please help analyze unconfirmed bugs in the list of serious regressions and work towards eliminating the remaining P1 regressions. As usual if we reach zero P1 regressions we are ready to branch and release GCC 6. The quality data below reflects categorizing bugs from the "no priority" P3 to others as well as our recent progress in eliminating regressions. Bugs with priority P1 and P2 affect primary and secondary targets while P4 and P5 might only affect the rest of targets and non-C/C++ frontends. Quality Data Priority # Change from last report --- --- P1 33+ 30 P2 103+ 19 P3 43- 103 P4 110+ 27 P5 30- 2 --- --- Total P1-P3 179- 54 Total 319- 29 Previous Report === https://gcc.gnu.org/ml/gcc/2015-11/msg00075.html
Re: Source Code for Profile Guided Code Positioning
On Tue, Jan 19, 2016 at 11:08 PM, Sriraman Tallam wrote: > > There is no documentation as such that I am aware of to write a linker > plugin. Here is a very brief overview. The linker calls the > plugin's "onload" function when registering the plugin and the plugin > inturn can register two call-backs with the linker, "claim_file_hook" > and the "all_symbols_read_hook". "claim_file_hook" is called for > each object file that the linker prcesses and the > "all_symbols_read_hook" is called after all the symbols have been read > by the linker. These are just two different interesting points in the > course of a link. > > The plugin can also get handles to linker functions like > "get_input_section_name" which it can use to process sections given > their handle. You can also check the gold linker tests for simpler > plugin examples. The linker plugin interface is somewhat documented at https://gcc.gnu.org/wiki/whopr/driver . Ian
gcc-4.9-20160120 is now available
Snapshot gcc-4.9-20160120 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160120/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 232636 You'll find: gcc-4.9-20160120.tar.bz2 Complete GCC MD5=759f3f4a3f1c07c3661d969e6bacae6d SHA1=6b0aa983008d9ed8bd9788a291ca879f99adc260 Diffs from 4.9-20160113 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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: SH runtime switchable atomics - proposed design
On Tue, 2016-01-19 at 15:28 -0500, Rich Felker wrote: > I've been working on the new version of runtime-selected SH atomics > for musl, and I think what I've got might be appropriate for GCC's > generated atomics too. I know Oleg was not very excited about doing > this on the gcc side from a cost/benefit perspective I am just not keen on making this the default atomic model for SH. If you have a system built around this atomic model and want to add it to GCC, please send in patches. Just a few comments below... > Inputs: > - R0: Memory address to operate on > - R1: Address of implementation function, loaded from a global > - R2: Comparison value > - R3: Value to set on success > > Outputs: > - R3: Old value read, ==R2 iff cas succeeded. > Preserved: R0, R2. > > Clobbered: R1, PR, T. The T bit is obviously the result of the cas operation. So you could use it as an output directly instead of the implicit R3 == R2 condition. > > This call (performed from __asm__ for musl, but gcc would do it as SH > "SFUNC") is highly compact/convenient for inlining because it avoids > clobbering any of the argument registers that are likely to already > be > in use by the caller, and it preserves the important values that are > likely to be reused after the cas operation. > > For J2 and future J4, the function pointer just points to: > > rts >cas.l r2,r3,@r0 > > and the only costs vs an inline cas.l are loading the address of the > function (done in the caller; involves GOT access) and clobbering R1 > and PR. > > This is still a draft design and the version in musl is subject to > change at any time since it's not a public API/ABI, but I think it > could turn into something useful to have on the gcc side with a > -matomic-model=libfunc option or similar. Other ABI considerations > for > gcc use would be where to store the function pointer and how to > initialize it. To be reasonably efficient with FDPIC the caller needs > to be responsible for loading the function pointer (and it needs to > always point to code, not a function descriptor) so that the callee > does not need a GOT pointer passed in. Obviously the ABI has been constructed around the J-core's cas.l instruction. Do you have plans to add other atomic operations (like arithmetic)? If not, then I'd suggest to name the atomic model "libfunc-musl-cas". Cheers, Oleg
Re: SH runtime switchable atomics - proposed design
On Thu, Jan 21, 2016 at 08:08:18AM +0900, Oleg Endo wrote: > On Tue, 2016-01-19 at 15:28 -0500, Rich Felker wrote: > > I've been working on the new version of runtime-selected SH atomics > > for musl, and I think what I've got might be appropriate for GCC's > > generated atomics too. I know Oleg was not very excited about doing > > this on the gcc side from a cost/benefit perspective > > I am just not keen on making this the default atomic model for SH. > If you have a system built around this atomic model and want to add it > to GCC, please send in patches. Just a few comments below... OK, thanks for clarifying. I don't have a patch yet but I might do one later. Sato-san's work on adding direct cas.l support showed me how this part of the gcc code seems to work, so it shouldn't be too hard to hook it up, but there are ABI design considerations still if we decide to go this way. > > Inputs: > > - R0: Memory address to operate on > > - R1: Address of implementation function, loaded from a global > > - R2: Comparison value > > - R3: Value to set on success > > > > Outputs: > > - R3: Old value read, ==R2 iff cas succeeded. > > > Preserved: R0, R2. > > > > Clobbered: R1, PR, T. > > The T bit is obviously the result of the cas operation. So you could > use it as an output directly instead of the implicit R3 == R2 > condition. I didn't want to impose a requirement that all backends leave the result in the T bit. At the C source level, I think most software uses old==expected as the test for success; this is the API __sync_val_compare_and_swap provides, and what people used to x86 would naturally do anyway. > > This call (performed from __asm__ for musl, but gcc would do it as SH > > "SFUNC") is highly compact/convenient for inlining because it avoids > > clobbering any of the argument registers that are likely to already > > be > > in use by the caller, and it preserves the important values that are > > likely to be reused after the cas operation. > > > > For J2 and future J4, the function pointer just points to: > > > > rts > > cas.l r2,r3,@r0 > > > > > and the only costs vs an inline cas.l are loading the address of the > > function (done in the caller; involves GOT access) and clobbering R1 > > and PR. > > > > This is still a draft design and the version in musl is subject to > > change at any time since it's not a public API/ABI, but I think it > > could turn into something useful to have on the gcc side with a > > -matomic-model=libfunc option or similar. Other ABI considerations > > for > > gcc use would be where to store the function pointer and how to > > initialize it. To be reasonably efficient with FDPIC the caller needs > > to be responsible for loading the function pointer (and it needs to > > always point to code, not a function descriptor) so that the callee > > does not need a GOT pointer passed in. > > Obviously the ABI has been constructed around the J-core's cas.l > instruction. Yes, but that was a choice I made after a first draft that was no more optimal for the other backends and less optimal for J-core. And the only real choices that were based on the instruction's properties were using r0 for the address input and swapping the old value into r3 rather than producing it in a different register. Other than these minor details ABI was guided more by avoiding clobbers/reloads of potentially valuable data in the caller. One possible change I just thought of: with one extra instruction in the J-core version we could have the result come out in r1 and preserve r3. Similar changes to the other versions are probably easy. > Do you have plans to add other atomic operations (like > arithmetic)? No, at least not in musl. From musl's perspective cas is the main one that's used anyway. But even in general I don't think there's a significant advantage to doing 'direct' arithmetic ops without a cas loop even when you can (with llsc, gusa, or imask model). With gusa and imask the only time you benefit from not implementing them in terms of cas is on the _highly_ unlucky/unlikely occasion where an interrupt occurs between the old-value read before cas and the cas. For llsc there's more potential advantage because actual smp contention is possible, but sh4a is probably not a very interesting target anymore. > If not, then I'd suggest to name the atomic model > "libfunc-musl-cas". I'm not sure how the "musl" naming here makes sense unless you're thinking of having it just call into musl's definitions, which is certainly a possible design but not what I had in mind. I was thinking of adapting the design to gcc and providing something similar via libgcc.a. Rich
Re: Hi! New to GCC
Thanks Mikhail, As you have suggested I have built gcc on my laptop and gone through all the videos. The videos were very informative. Can I use any IDE for browsing gcc source code ? Should I start looking at the "easy hacks" ? On 9 January 2016 at 21:25, Mikhail Maltsev wrote: > On 01/09/2016 06:10 PM, Prasad Ghangal wrote: >> Hi, >> I am Prasad Ghangal, a BTech student and I really want to contribute >> in gcc, but I am new to open source community. >> I can code in C,C++ and know little python. I have successfully built >> gcc on my local machine as instructed. >> >> So can someone please help me getting started? >> > Hi! > > Here is a list of first steps to start with: > https://gcc.gnu.org/wiki/GettingStarted > > Also, you might want to take a look at these video lectures: > https://www.cse.iitb.ac.in/grc/index.php?page=videos, they are slightly > outdated > (~2012), but still give a good overview of GCC internals. > > There is a list of bugs and enhancement requests, which were marked by GCC > developers as "easy hacks", i.e. something that should be easy enough for new > contributors to start with: > https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=easyhack&list_id=135581&resolution=--- > > > -- > Regards, > Mikhail Maltsev -- Thanks and Regards, Prasad Ghangal
