Re: GSOC
On Wed, Mar 14, 2018 at 5:34 PM, Martin Jambor wrote: > Hello Prashant, > > On Thu, Mar 08 2018, prashant kumar wrote: >> Hello sir my self *Prashant kumar *second year B.TECH student and i am >> interesting in *"GCC plugin Api" *project .i have a good hand in c,c++ >> languages .Can u tell me what the further process i have to do and what >> kind of thing i have to do > > first and foremost, please discuss any GSoC idea or topic, use the > gcc@gcc.gnu.org mailing list (CCed), this way other people may also > participate in the discussion which will eventually help you as well. > Moreover, in your particular case, you sent me your message while I was > on vacation and so it took quite some time before I got to replying. > Other members of the GCC community might have done that meanwhile. > > The aim of the gcc API project would be to start building a real GCC API > for plugins, so that simple but already useful plugins (operating on > GIMPLE level) could be written that use only this API (as opposed to the > current state where they can - actually they have to - use any normal > public symbol there is in GCC. I do not think it is reasonable to > attempt make the API really entirely compiler agnostic but whenever > practical, the interface should be built on top of generic compiler > constructs (e.g. statements and operands as opposed to gimple and > trees), for many reasons. > > In the first half of the project one would aim to build various dumping > plugins... that would simply dump CFG, statements and perhaps also some > information about types queried through the new interface. In the > second half, you should try to rewrite some existing simple plugins > using this API (such as https://pagure.io/funcp-encrypt that is > described at > https://developers.redhat.com/blog/2017/03/17/diagnosing-function-pointer-security-flaws-with-a-gcc-plugin/ > or perhaps the structleak_plugin.c kernel GCC plugin or > https://rwmj.wordpress.com/2016/02/24/playing-with-gcc-plugins/ though I > have not had a very close look any of those). > > If you are interested, make sure you can check out the GCC trunk source > code, can build GCC from it. The following links should help you: > > - How to check out our sources using svn and git is described at >https://gcc.gnu.org/svn.html and https://gcc.gnu.org/wiki/GitMirror >respectively. > > - Steps linked from https://gcc.gnu.org/install/ show you how to >configure, build and test GCC is described in (look for >--disable-bootstrap, among other things). > > - Also make sure you also look at https://gcc.gnu.org/wiki/InstallingGCC and >https://gcc.gnu.org/wiki/GettingStarted wiki pages. > > And while you are at it, try also to look at the source. But you have > gone through all of the above and still find a little bit intimidating > or difficult to see where to start looking, do not despair. That is > something the mentors and the community at large are willing to help > you with. > > Regarding plugins, I'd suggest reading one ore more tutorials on their > current implementation > (e.g. http://thinkingeek.com/2015/08/16/a-simple-plugin-for-gcc-part-1/) > and then look at some real plugins to get the sense of what would need > to be APIzied. Note that there are also (half-way?) finished implementations, several that allow writing plugins in other languages (python, etc.) that usually come with "shim" layers to support multiple GCC versions underneath. Those "shim" layers are a good hint at what needs abstracting. There's also an incomplete attempt at providing a mostly compiler-agnostic plugin API for introspection (but techincally not limited to that). Not sure if Micha ever posted what he had implemented. If I had to choose then I would suggest to embed a "common" shim layer into GCC itself and call that the C plugin API. The python plugin API implementation should be able to bolt on that as well as the introspection API. This means the GSoC project would be about implementing such a layer (and eventually simply start by picking one of the available out-of-tree ones, massaging it so it can replace the others). And of course documenting it, doing some "real" example plugins using that layer directly. Richard. > Good luck, > > Martin
Re: GSOC 2018 - Textual LTO dump tool project
On Wed, Mar 14, 2018 at 8:13 PM, Hrishikesh Kulkarni wrote: > Hi, > > Thanks a lot for inputs and guidance. I have incorporated all the changes in > the document. Shall I go ahead and submit the proposal formally on GSOC > website? Yes, I think it's fine to submit it - but let's ask the Mentor for the project, Martin, for his opinion first. Martin? Thanks, Richard. > Drive link to Proposal: > https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7ljTDLS1xMwvK5w/edit > > Regards, > > Hrishikesh > > On Wed, Mar 14, 2018 at 8:28 PM, Richard Biener > wrote: >> >> On Tue, Mar 13, 2018 at 5:30 AM, Hrishikesh Kulkarni >> wrote: >> > Hi, >> > >> > Thanks. I have tried to incorporate suggestions and prepared a revised >> > draft >> > of proposal for GSOC. Please find the same attached herewith. Your >> > suggestions in regard with this draft would definitely help me to >> > improve it >> > further for submission. >> >> Thanks, it looks very good now. You have essentially duplicated items >> in 1. and 2., namely --summary= and Dumping of IPA summaries. >> I would move some of the 1. items over to 2., apart from --summary I'd >> also >> move --cgraph-dot. >> >> Richard. >> >> > >> > Drive link to Draft Proposal: >> > >> > >> > https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7ljTDLS1xMwvK5w/edit >> > >> > >> > Regards, >> > >> > Hrishikesh >> > >> > >> > >> > >> > On Mon, Mar 12, 2018 at 4:45 PM, Richard Biener >> > >> > wrote: >> >> >> >> On Sun, Mar 11, 2018 at 8:23 PM, Hrishikesh Kulkarni >> >> wrote: >> >> > Hi, >> >> > >> >> > Greetings! Please find my draft proposal for GSOC attached herewith. >> >> > I >> >> > am >> >> > very grateful to all of you for your inputs, suggestions and >> >> > directions. >> >> > I >> >> > have tried to assimilate these inputs received from you to convert it >> >> > into a >> >> > proposal. Your suggestions in regard with this draft would definitely >> >> > help >> >> > me to convert it into final proposal for submission. In addition, >> >> > could >> >> > you >> >> > please suggest the possible extensions those can be added to dump >> >> > tool? >> >> > >> >> > >> >> > Drive link to Draft Proposal: >> >> > >> >> > >> >> > >> >> > https://docs.google.com/document/d/1-jYwwDWsHQwMaxVsHFBrJ9EiCAev7ljTDLS1xMwvK5w/edit >> >> >> >> The proposal looks a bit sparse when giving details about the actual >> >> project. >> >> I'd suggest to clarify at least the deliverables. I suggest for 1. add >> >> a >> >> 1 c) >> >> that specifies what should be working, for example >> >> >> >> lto-dump -l >> >> >> >> should dump a list of variables and functions contained in the IL >> >> >> >> lto-sump -s >> >> >> >> should dump detailed info about the symbol (using the symtab dump >> >> infrastructure) >> >> >> >> lto-dump -f >> >> >> >> should dump the function body of the function with (using the >> >> gimple >> >> dump infrastructure) >> >> >> >> the lto-dump tool should be verified to work on both WPA-time and >> >> LTRANS-time >> >> objects. >> >> >> >> Thus your 2) a) should be possible with 1) already. 2) would then >> >> contain >> >> dumping of IPA summaries as major part apart from visualizing the >> >> callgraph. >> >> For visualizing the (full) callgraph you need to handle multiple LTO >> >> IL input files. >> >> Those two pieces should be enough for 2) unless usability issues spill >> >> over >> >> from 1). >> >> >> >> In the introduction I miss some general words about the LTO IL, like >> >> that >> >> it >> >> is non-self-describing bytecode which is documented only by the code >> >> reading/writing it and thus hard to debug. It also misses to lay out >> >> the >> >> overall structure of a LTO IL file (you are already going into detail >> >> with >> >> IPA passes so this missing stands out). >> >> >> >> Richard. >> >> >> >> > >> >> > Regards, >> >> > >> >> > Hrishikesh >> >> > >> >> > >> >> > >> >> > On Tue, Mar 6, 2018 at 8:59 PM, Jan Hubicka wrote: >> >> >> >> >> >> > On Tue, Mar 6, 2018 at 4:02 PM, Jan Hubicka >> >> >> > wrote: >> >> >> > >> On Tue, Mar 6, 2018 at 2:30 PM, Hrishikesh Kulkarni >> >> >> > >> wrote: >> >> >> > >> > Hi, >> >> >> > >> > >> >> >> > >> > Thank you Richard and Honza for the suggestions. If I >> >> >> > >> > understand >> >> >> > >> > correctly, >> >> >> > >> > the issue is that LTO file format keeps changing per compiler >> >> >> > >> > versions, so >> >> >> > >> > we need a more “stable” representation and the first step for >> >> >> > >> > that >> >> >> > >> > would be >> >> >> > >> > to “stabilize” representations for lto-cgraph and symbol >> >> >> > >> > table ? >> >> >> > >> >> >> >> > >> Yes. Note the issue is that the current format is a 1:1 >> >> >> > >> representation of >> >> >> > >> the internal representation -- which means it is the internal >> >> >> > >> representation >> >> >> > >> that changes frequently across releases. I'm not sure how >> >> >> > >> Honza >> >> >> > >> wants >> >> >> > >> to de
Re: GSOC 2018 - Textual LTO dump tool project
On 03/15/2018 09:45 AM, Richard Biener wrote: > Yes, I think it's fine to submit it - but let's ask the Mentor for the > project, Martin, for his > opinion first. > > Martin? > > Thanks, > Richard. Hi. Sorry for the delay and thanks to Richi who's been co-mentoring the project. I've just read the submission draft and it looks nice! Please submit it. Martin
Re: GSoC
Hello Gurav, On Thu, Mar 15 2018, Gaurav Ahuja wrote: > I had a query, while choosing project for GSoC. Actually I'm > contributing to GCC for the first time, and I am not sure about what > is expected of me. > > So, can you please explain me about , what GCC organisation expects me > to do, like detect bugs, or add a new feature ,etc.? I am not sure I understand your question. GCC as an GSoC organization does not give prospective students any tasks they need to complete before applying. However, it is a good idea to at least check out, build and test the compiler suite before you apply for a project with us. See the information at https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and generally speaking the entire wiki page on GSoC for what to do. Martin
Re: Queries on GSoC project on OMPD interface
On Wed, Mar 14, 2018 at 06:01:20PM +0100, Martin Jambor wrote: > Hello Siyuan, > > On Mon, Mar 12 2018, LIU SIYUAN wrote: > > Dear all, > > > > Hi, my name is Siyuan and this is my first time using the GCC mailing list! > > Welcome! Yeah, welcome. > For the OMPD task, you will primarily want to look at the OMP run-time > that is in the libgomp subdirectory (and on the libgomp.exp part of the > testsuite). You will probably also want to have a look at how to build > GDB. > > The OMPD itself is described in the latest TR of the upcoming version of > the OpenMP standard: > http://www.openmp.org/wp-content/uploads/openmp-TR6.pdf > > I assume that once you familiarize with the standard and look at how the > OpenMP run-time is organized (at least roughly), you will want to reach > out to Jakub (CCed) to figure out how to structure your work. The task would be to add the libgompd.so.1 library and header files which implement the APIs in the 4.2 OMPD section of the above spec (and any further changes that get ratified into upcoming OpenMP 5.0) and any necessary changes on the libgomp.so.1 side needed for that. For the latter, it is important to make sure the changes don't slow the runtime down, or don't slow it down significantly if there is no other way, and it would be nice to use some framework like https://infinitynotes.org/wiki/Infinity to communicate structure offsets, flags, etc. between the libgompd.so.1 and libgomp.so.1, so that if possible a debugger could bypass the plugin library and e.g. for performance reasons use the bytecode directly or that one version of the plugin can deal with slightly different version of the runtime library (e.g. for the case of running debugger in one platform and gdb server + libgomp on another one). Jakub
Internal compiler error building libstdc++ for vax
Hi folks,
netbsd's copy of GCC differs enough that it fails elsewhere with
gcc-trunk, but the problematic code is upstream.
updating netbsd to gcc 6.4.0, I get an internal compiler error building
libstdc++. (Long version: http://gnats.netbsd.org/53039)
Short version:
test.cc: In function 'bool
std::atomic_flag_test_and_set_explicit(std::__atomic_flag_base*,
std::memory_order)':
test.cc:25:3: internal compiler error: in patch_jump_insn, at cfgrtl.c:1271
comment at cfgrtl.c:1271 suggests:
/* If the substitution doesn't succeed, die. This can happen
if the back end emitted unrecognizable instructions or if
target is exit block on some arches. */
if (!redirect_jump (as_a (insn),
block_label (new_bb), 0))
{
gcc_assert (new_bb == EXIT_BLOCK_PTR_FOR_FN (cfun));
so it's saying the backend is generating garbage.
(gdb) call debug_insn_slim(insn)
12:
{pc={(zero_extract([r23:SI],0x1,0x1)!=0)?L14:pc};zero_extract([r23:SI],0x1,0x1)=0x1;}
I've found that if I modify vax/builtins.md:
@@ -61,7 +67,7 @@
label = gen_label_rtx ();
emit_move_insn (operands[0], const1_rtx);
- emit_jump_insn (gen_jbbssi (operands[1], const0_rtx, label,
operands[1]));
+ //emit_jump_insn (gen_jbbssi (operands[1], const0_rtx, label,
operands[1]));
emit_move_insn (operands[0], const0_rtx);
emit_label (label);
DONE;
it "fixes" my internal compiler error. However, I'm not sure what is
wrong with gen_jbbssi.
My current strategy of "just changing things and seeing if they help /
comparing to 50 examples of nearly identical code" doesn't appear
to be working despite many attempts :-)
Please help, thanks.
Blog post about gcc 8 usability improvements
Sorry for the shameless self-promotion, but I've written up the work I've done on gcc 8 usability, in blog form, here: https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/ I'm working on a patch for the website's changes.html, covering the same material. Dave
gcc-7-20180315 is now available
Snapshot gcc-7-20180315 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180315/ 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 258574 You'll find: gcc-7-20180315.tar.xzComplete GCC SHA256=98677b19ec9cb85206cc1d4ced56c344b1ca9059529e572ca3d6031654a486a6 SHA1=23204b877437719dd0d2c2cc4f8140e744df6852 Diffs from 7-20180308 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: Blog post about gcc 8 usability improvements
On 3/15/18, David Malcolm wrote: > Sorry for the shameless self-promotion, but I've written up the work > I've done on gcc 8 usability, in blog form, here: > > https://developers.redhat.com/blog/2018/03/15/gcc-8-usability-improvements/ > > I'm working on a patch for the website's changes.html, covering the > same material. > > Dave > Thank you re: the updating the changes.html part; I was thinking it was looking rather bare compared to previous changes.html pages at this same point in previous release cycles... Eric
