Re: HelloGcc 2011 Workshop calling for topic speakers
Hey Hui, I put the GCC development mailing list on CC ... Andi HelloGcc Working Group was set up in 2007 by Chinese free software fans and developers in Beijing. With the goal of constructing a free, open, sharing technical community, we not only discuss and learn about GNU system tools(such as GCC, GDB, Binutils etc), provide helps on related study and work, but also make our contributions to free software community. Every year, we hold a technical workshop in order to improve communication among open source developers and fans. The activity will be held in Oct. this year. We're calling for topic speakers now. As soon as you prefer to give a technical report, welcome to contact us. Topics includes, but not limited to, * Introduction on your original work, or the work of others. * Researching work or engineering work. * Code explanation and program demonstration. * etc, We need to get the speaker's slides ahead of time and post it on the Internet, with author's approval. It's better if you intend to provide the text of articles, of course. The whole activity is free. We hope to get some sponsorship to be used as the reward of speakers and the support of the community development. Please send mail to following address below if you have any questions on this workshop: hellogcc.workgr...@gmail.com Note: Topics in HelloGcc 2010 Workshop (http://hellogcc.blogbus.com/c3688812). * Memory management mechanism and optimization * Discussion on debugger's breakpoint mechanism * Bintuils porting to embedded CPU * Implementation and discussion on visualization of GCC * How To Port GNU ToolChain * Demo of Linux Kernel GDB tracepoint module Topics in HelloGcc 2009 Workshop. * Analyze and improve the program's data locality with GCC * GCC Internals and Porting * gdbproxy: An open source GDB stub for Blackfin * GDB reverse debug and process record and replay target You can find us on * blog: http://hellogcc.blogbus.com * mail list: http://www.freelists.org/archive/hellogcc * irc: #hellogcc（freenode） -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"White paper" about GCC front-end internals
Hey ALL, after some time of source code investigations, testing and experiments, I finally bundled my experiences with GCC front-ends in a "white paper" about the internals of GCC front-ends. It is not really structured like a tutorial, but it should hopefully be usuable by GCC newbies to speed up the introduction into GCC. The white paper is available at: http://blog.lxgcc.net/wp-content/uploads/2011/03/GCC_frontend.pdf I'm pretty sure that this paper still contains some errors or even conceptual mis-understandings, though I would appreciate to get feedback of any kind about what could be improved/changed/removed. Once, all erros and mis-understandings are removed, I would then put some important extracts of this paper into the GCC internals documentation to serve as a base for future front-end documentations. Thanks for your feedback and time, Andi
Re: gcc terms of use
Hey, When I build my software products via gcc can I use it with third party's proprietary software (not open source)? Yes. When I build my software products via gcc I must provide source code of my products in any case? No. You don't need to publish _your_ source code in this case. There are some big (proprietary) software companies out there who use GCC. Generally, the open source thing relates to the sources of the compiler itself, but not to the sources which are built by GCC. Andi P.S. Please do not use gcc@gcc.gnu.org for such kind of questions. There's a specific mailing list gcc-h...@gcc.gnu.org which is the appropriate one.
Re: gcov/-ftest-coverage instrumentation for uninstantiated C++ function templates
Hey Manuel,
I would like to be able to change this behaviour so non-instantiated
code templates are considered as blocks (I think this is the term used
by GCC/GCov). This would help me greatly to uncover unused/untested
codes in a header/template-only library.
First of all: Is this feasible with the GCC infrastructure?
I am not sure about that. It could be harder to get this implemented
since the required information might not be available when you require it.
For this to work, one would probably need access to the internal
representation of the program. It is my understanding that there are
at least two distinct representations of a C++ program: (1) The AST
that only contains the parse tree, before any template instantiation
and (2) the intermediate language representation (GIMPLE?) that will
contain a representation of the instantiated templates. On which level
is coverage instrumentation added right now?
Yes, that's true. You get the details of both representations by using
the additional compiler flags
-fdump-translation-unit (prints out an extended version of GENERIC (= AST))
-fdump-tree-gimple-raw (prints out the second IR known as GIMPLE)
The instrumentation of the source code is finally done on the GIMPLE IR.
You could print out the IR by specifiying -fdump-tree-tree_profile
Second: Where would I start looking?
So far, I have discovered gcov*.{h,c} in the gcc directory. However, I
have not yet found where the .gcno files are written out in the compiler.
There was a recent discussion on the gcc-help mailing list about the
basic internals of GCOV. Please find the thread here:
http://gcc.gnu.org/ml/gcc-help/2011-04/msg00072.html
Third: How hard would it be and how would I proceed?
Naively, my first guess at an approach would be: Locate where the
.gcno file is written out. After writing out all real blocks, identify
all uninitialized template functions, or member functions that are
members of templates, etc. etc. Add a "block" to the .gcno file for
each such function.
As listed above, the .gcno file is written in coverage.c, though you
should look at this one.
I hope that this helps at least a bit to get a step further ...
Best regards,
Andi
Re: Interested In Doing Documentation Project
Hi Selma, I am interested in doing the front end documentation project. How do I sign up for that, or learn what is going on with it at this current time please? Perfect and thanks for your interest in doing documentation for GCC. Andi Hellmund and i have actually done alot of work into front-end documentation work maybe you could sync with us if your interested how did you find this as a project and what are you interested in? As Phil said, we have already been doing some work in the front-end space and here's a link to a basic whitepaper about GCC front-end internals. It is far away from being complete, but maybe a foundation for some future work ... http://blog.lxgcc.net/wp-content/uploads/2011/03/GCC_frontend.pdf Best regards, Andi
Re: The AST tree modification. Edited.
Hi,
as an addition to Balaji's answer. Please find attached an extract of a
sample front-end generating various types of tree nodes (e.g. arrays,
structs, ...). This used to work with an older version of GCC, but I'm
not sure if this still works with the most recent version. Anyway, it
should give you some pointers for further investigations ...
Best regards,
Andi
Hello,
For most of the things you are looking for, please look for a function
called build_decl. It is used in several places inside GCC. Let me give you a
small example,
If you do the following:
tree x = build_decl (UNKNOWN_LOCATION, VAR_DECL, get_identifer("ii"),
integer_type_node)
you will declare a variable called "ii" of type "integer."
Similarly, to create a new internal structure, if do something like this:
tree struct_frame = lang_hooks.make_type (RECORD_TYPE);
tree struct_field = build_decl (UNKNOWN_LOCATION, FIELD_DECL,
get_identifier("variable"), integer_type_node)
TREE_CHAIN(struct_field) = struct_frame
You will create the following internal structure
struct {
int variable;
}
I hope this helps you get started.
Thanks,
Balaji V .Iyer.
-Original Message-
From: niXman [mailto:i.nix...@gmail.com]
Sent: Monday, October 03, 2011 6:51 PM
To: gcc@gcc.gnu.org
Subject: The AST tree modification. Edited.
Hi everybody!
It is necessary to implement a plug-in for GCC designed to collect the
information on types of translation unit, and generate static const array of
types rtti_ex _ on its base; //
enum class type_ {
char_, uchar_, short_, ushort_, int_, uint_, long_, ulong_,
int64_, uint64_, array_, pointer_, double_, long_double_, float_,
class_
};
struct rtti_ex_ { //<
const char* name;
const type_ type;
const size_t size;
const size_t align;
const size_t offset;
};
// generated from plugin.
static const rtti_ex_ rtti_ex_array_[] = {
{...},
{...},
{...}
};
/
There aren't any problems with information collection from AST. There is a
complexity with AST modification:
1. How to declare a variable?
2. How to declare the typedef?
3. How to declare a structure?
4. How to declare an array of structures?
I suppose that there should be a function like: tree make_subtree (const char*
source); which result I could insert in the corresponding node. But I haven't
found it.
Please, give me some links on this subject. It is very desirable, if you could
give some links with examples.
Thanks.
#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"
#include "tree.h"
#include "tree-dump.h"
#include "tree-iterator.h"
#include "gimple.h"
#include "function.h"
#include "flags.h"
#include "output.h"
#include "ggc.h"
#include "toplev.h"
#include "varray.h"
#include "langhooks-def.h"
#include "langhooks.h"
#include "target.h"
#include "cgraph.h"
#include "sfe1.h"
#include "opts.h"
#include "input.h"
/* static unsigned int global_var = 0; */
tree create_decl__global_var ()
{
tree __glob_id = get_identifier("global_var");
tree __glob_decl = build_decl(VAR_DECL, __glob_id, unsigned_type_node);
/* allocate static storage for this variable */
TREE_STATIC(__glob_decl) = true;
/* static: internal linkage */
TREE_PUBLIC(__glob_decl) = false;
/* the context of this declaration: file scope */
DECL_CONTEXT(__glob_decl) = NULL_TREE;
/* this declaration is used in its scope */
TREE_USED(__glob_decl) = true;
/* initialization to 0 */
tree __glob_init_val = build_int_cstu(unsigned_type_node, 1);
DECL_INITIAL(__glob_decl) = __glob_init_val;
layout_decl(__glob_decl, false);
rest_of_decl_compilation(__glob_decl, 1, 0);
return __glob_decl;
}
tree create_decl__str ()
{
tree __str_id = get_identifier("str");
/* create a new type for const char */
tree __str_array_type = build_array_type(char_type_node, build_index_type(build_int_cst(NULL_TREE, 18)));
tree __str_type = build_pointer_type(char_type_node);
tree __str_array_ptr_type = build_pointer_type(__str_array_type);
tree __str_decl = build_decl(VAR_DECL, __str_id, __str_type);
TREE_STATIC(__str_decl) = true;
/* external linkage */
TREE_PUBLIC(__str_decl) = true;
DECL_CONTEXT(__str_decl) = NULL_TREE;
TREE_USED(__str_decl) = true;
/* initialization to constant/read-only string */
tree __str_init_val = build_string(18, "Global Value: %u\n");
TREE_TYPE(__str_init_val) = __str_array_type;
TREE_CONSTANT(__str_init_val) = true;
TREE_STATIC(__str_init_val) = true;
TREE_READONLY(__str_init_val) = true;
tree adr_expr = build1(ADDR_EXPR, __str_array_ptr_type, __str_init_val);
tree nop_expr = build1(NOP_EXPR, __str_type, adr_expr);
DECL_INITIAL(__str_decl) = nop_expr;
layout_decl(__str_decl, false);
rest_of_decl_compilation(__str_decl, 1, 0);
return __str_decl;
}
tree create_type__fptr_t ()
{
tree __arg0_type = build_pointer_type(signed_char_type_node);
tree __arg1_
Re: Why not contribute? (to GCC)
Hey, are these documents, copyright assignment and employer disclaimer, publicly available in the WEB or do I need to explicitly request these documents? I plan to start contributing in the near future and I'm currently in the process to get the approval from my employer. After getting the company approval, the next obvious step would be to sign these FSF documents. If someone could send me a link (I searched through the web but couldn't find any links at GCC, GNU and FSF) would be really helpful ... Thanks, Andi
Re: Why not contribute? (to GCC)
Richard Guenther wrote: Indeed - we do not need another piece of infrastructure. Note that good patch review takes a lot of time and we (unfortunately again) do not have many active patch reviewers. So it happens that patches from people with excellent track history get approved quickly but others are just left behind. Pinging the patches does usually help here, as well as working with maintainers during the patch creation so that the final review is easy. Richard. This all sounds like a typical "dead-lock" problem. The projects obviously needs more patch reviewers, but to be qualified for a patch reviewer, you clearly require a _thorough_ understanding of the GCC internals. And I think to get this deep knowledge - at least for my person - I need the motivation to look and work through the source code to understand the internals. And to get this motivation or keep it up and running, I need to work productively on this project by submitting patches among others. Documentation is important and could make fun as well, but the real fun is to work on the code and submit - at one time - patches to the main line. All the mentioned aspects sound somehow devastating for me that it is _that_ hard to get into the real contribution and I could generally understand that a lot of persons decided to NOT contribute. Although some might think this is stupid SPAM, I think this thread is really good (Thanks Manuel!) to get an overview of the current "problems" of the GCC projects and what could be improved so that the project becomes more attractive to potential contributors. A patch tracking system might basically be a good idea for contributors but it nevertheless doesn't solve the real problem, the limited amount and time of the patch reviewers!!!
[LTO] Open items in the ToDo list
Hey, I was recently reading through the wiki pages of the LTO branch and found several open items in the ToDo list which are generally interesting. I mainly kept an eye on item 7 (Browsing/dumping tools for LTO files), which seems for me to be a good task to deepen the knowledge about GCC internals. Is someone already working on this item? Or are there any reasons to NOT start working on this item? :-) It is not only related to this ToDo list of LTO, but to all ToDo lists in the wiki. I think we should try to keep the ToDo lists up-to-date in the sense that someone working on an item should put his/her name in the list to signal that this item is work-in-progress. Others could then specifically contact this person if they would like to contribute/support. Thanks, Andi
Re: âx--â would self-add before opration "-- " ï¼
> I am not familar with both c++ and compiler implementation, donot konw > why the results are differnt for gcc and clang. Anyone could help and > explain this difference for me? The ISO C standard says that the evaluation order of function arguments is unspecified [ISO C99, 6.5.2.2-11], though the implementation (GCC vs. clang) is free to choose which evaluation order to use. That's why you see these differences between GCC and clang. Andi
Re: PL/1 frontend
Hey Tom, You need to define a lang_tree_node type, even if its empty. See the lto frontend example. You could also look at this site (http://code.redbrain.co.uk/cgit.cgi/gcc-dev/tree/gcc/gcalc?h=documentation). It contains the front-end code for a very simple front-end showing the general/expected structure of the front-end. The code isn't yet optimal, but it should help you to figure out what you really need to build-up the front-end. If you have any specific questions about front-ends and how to pass data to the middle-end feel free to ask on this list :-) Hope that helps, Andi
Re: PL/1 frontend
Nice. Thanks for doing this. If it's not already there, could you add a link to this in http://gcc.gnu.org/wiki/GettingStarted ? Sure, Phil (Herron) and I could post it there. Ideally, we should also have a more-or-less thorough documentation in the gcc internals document about howto implement front-ends, etc. We already have an initial version (I think it is in the documentation branch), but it is still missing quite a lot. So, if Ian possibly has further recommendations for front-ends, we could include them adequately. Thanks, Andi
