Compiling GCC problems
configure went well but I keep hitting: ../.././gcc/gengtype.c:963: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1098: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1154: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1164: error: undefined reference to 'lexer_line' ../.././gcc/gengtype-parse.c:53: error: undefined reference to 'yylex(char const**)' ../.././gcc/gengtype-parse.c:1044: error: undefined reference to 'yybegin(char const*)' ../.././gcc/gengtype-parse.c:1070: error: undefined reference to 'lexer_toplevel_done' ../.././gcc/gengtype-parse.c:1075: error: undefined reference to 'yyend()' I've installed flex, bison and yacc (should it use it, it seems to be using bison -y) (if I hadn't have installed flex would it's "missing" ones have worked? What's wrong? It does configure fine! Alec
Re: Compiling GCC problems
On 23/01/13 08:16, Alec Teal wrote: configure went well but I keep hitting: ../.././gcc/gengtype.c:963: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1098: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1154: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1164: error: undefined reference to 'lexer_line' ../.././gcc/gengtype-parse.c:53: error: undefined reference to 'yylex(char const**)' ../.././gcc/gengtype-parse.c:1044: error: undefined reference to 'yybegin(char const*)' ../.././gcc/gengtype-parse.c:1070: error: undefined reference to 'lexer_toplevel_done' ../.././gcc/gengtype-parse.c:1075: error: undefined reference to 'yyend()' I've installed flex, bison and yacc (should it use it, it seems to be using bison -y) (if I hadn't have installed flex would it's "missing" ones have worked? What's wrong? It does configure fine! Alec checking for version 0.11 of ISL... no The following languages will be built: c,c++,fortran,java,lto,objc *** This configuration is not supported in the following subdirectories: gnattools target-libada target-libgo target-libbacktrace (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug *** removing build-x86_64-unknown-linux-gnu/libiberty/Makefile to force reconfigure *** removing build-x86_64-unknown-linux-gnu/fixincludes/Makefile to force reconfigure Noticed this in the config output, should this really be silent? Alec
Re: Compiling GCC problems
On 23/01/13 08:19, Alec Teal wrote: On 23/01/13 08:16, Alec Teal wrote: configure went well but I keep hitting: ../.././gcc/gengtype.c:963: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1098: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1154: error: undefined reference to 'lexer_line' ../.././gcc/gengtype.c:1164: error: undefined reference to 'lexer_line' ../.././gcc/gengtype-parse.c:53: error: undefined reference to 'yylex(char const**)' ../.././gcc/gengtype-parse.c:1044: error: undefined reference to 'yybegin(char const*)' ../.././gcc/gengtype-parse.c:1070: error: undefined reference to 'lexer_toplevel_done' ../.././gcc/gengtype-parse.c:1075: error: undefined reference to 'yyend()' I've installed flex, bison and yacc (should it use it, it seems to be using bison -y) (if I hadn't have installed flex would it's "missing" ones have worked? What's wrong? It does configure fine! Alec checking for version 0.11 of ISL... no The following languages will be built: c,c++,fortran,java,lto,objc *** This configuration is not supported in the following subdirectories: gnattools target-libada target-libgo target-libbacktrace (Any other directories should still work fine.) checking for default BUILD_CONFIG... bootstrap-debug *** removing build-x86_64-unknown-linux-gnu/libiberty/Makefile to force reconfigure *** removing build-x86_64-unknown-linux-gnu/fixincludes/Makefile to force reconfigure Noticed this in the config output, should this really be silent? Alec /sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libisl.so.8.0.0-gdb.py is not an ELF file - it has the wrong magic bytes at the start. cannot fix this, even running it directly python has no module "gdb", is this the source?
Re: libatomic multilib testing
"Steve Ellcey " writes: > Additionally, when the testing is finished I exit with a 'Error 2', but I > think most testing, even when there are problems, should exit with '0'. No, that has never been the case. Run make with -k. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: hard typdef - proposal - I know it's not in the standard
On 23 January 2013 06:53, Alec Teal wrote: > Why not: > > make an "optional keyword", "hard", have a meaning if before "typedef", I > suggest tokenising "hard" as a normal token (however it is processed now why > change it? I am not sure on GCCs exact grammar for c languages) but if AND > ONLY if it is before a "typdef" treat it differently, as far as I know a > typedef can only occur at the beginning of a statement so this should mean > it doesn't break anything. Like other specifiers such as const and static, typedef doesn't have to come first, i.e. this is legal, if unconventional: typedef int hard; hard typedef Int; I think Basile's suggestion to implement it as an attribute is a better idea, it makes it clearer it's something non-standard and compiler-specific, and the grammar already contains attributes in declarations. > Problems: > > 1)Not all compilers would be happy with this. > Fix: > I'm sure gcc must define something for the preprocessor that'll exist if and > only if GCC is the compiler? Nope, Compilers that claim GCC compatibility also define __GNUC__, and as has been discussed before on this list, if we added __REALLY_GCC__ then other compilers would just add that too.
Re: gcc : c++11 : full support : eta?
On 23 January 2013 07:11, Uday Khedker wrote: > > This is because no matter what one has done, unless one has contributed > code, one is not considered a contributor to GCC. There are people credited in http://gcc.gnu.org/onlinedocs/gcc/Contributors.html for documentation or bug triage work.
Re: Compiling GCC problems
Please use the gcc-help mailing list for discussing using and building GCC, rather than this list. Please take any follow up there, thanks. On 23 January 2013 08:25, Alec Teal wrote: > On 23/01/13 08:19, Alec Teal wrote: >> >> On 23/01/13 08:16, Alec Teal wrote: >>> >>> configure went well but I keep hitting: >>> >>> ../.././gcc/gengtype.c:963: error: undefined reference to 'lexer_line' >>> ../.././gcc/gengtype.c:1098: error: undefined reference to 'lexer_line' >>> ../.././gcc/gengtype.c:1154: error: undefined reference to 'lexer_line' >>> ../.././gcc/gengtype.c:1164: error: undefined reference to 'lexer_line' >>> ../.././gcc/gengtype-parse.c:53: error: undefined reference to >>> 'yylex(char const**)' >>> ../.././gcc/gengtype-parse.c:1044: error: undefined reference to >>> 'yybegin(char const*)' >>> ../.././gcc/gengtype-parse.c:1070: error: undefined reference to >>> 'lexer_toplevel_done' >>> ../.././gcc/gengtype-parse.c:1075: error: undefined reference to >>> 'yyend()' >>> >>> I've installed flex, bison and yacc (should it use it, it seems to be >>> using bison -y) (if I hadn't have installed flex would it's "missing" ones >>> have worked? >>> >>> What's wrong? It does configure fine! I'm not sure what you're asking. I assume those errors were *before* you installed flex? To build from source you need flex, as documented at http://gcc.gnu.org/install/prerequisites.html The configure script doesn't check for it because it's only needed when building from subversion or source snapshots. For packaged releases the files generated by flex are included in the tarball and flex is not required, so configure should not fail if users don't have it. We could make configure only require it for source snapshots, and generate a different configure for release tarballs, but that would be an extra maintenance burden and we'd probably accidentally end up with a release that checked for flex when it shouldn't. Instead we just require those working with development sources to install flex if building from source and it works. >> checking for version 0.11 of ISL... no >> The following languages will be built: c,c++,fortran,java,lto,objc >> *** This configuration is not supported in the following subdirectories: >> gnattools target-libada target-libgo target-libbacktrace >> (Any other directories should still work fine.) >> checking for default BUILD_CONFIG... bootstrap-debug >> *** removing build-x86_64-unknown-linux-gnu/libiberty/Makefile to force >> reconfigure >> *** removing build-x86_64-unknown-linux-gnu/fixincludes/Makefile to force >> reconfigure >> >> >> Noticed this in the config output, should this really be silent? I think this comes from autotools boilerplate stuff. > /sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libisl.so.8.0.0-gdb.py is not > an ELF file - it has the wrong magic bytes at the start. > > > cannot fix this, even running it directly python has no module "gdb", is > this the source? Ignore the warning. The file contains python pretty printers which are autoloaded by gdb when /usr/lib/x86_64-linux-gnu/libisl.so.8.0.0 is loaded, as such it has to be in the same directory as the shared lib, but that means ldconfig tries to process it and fails. The warning is harmless. There's a bugzilla report somewhere about warnings about the similar libstdc++.so.6.0.16-gdb.py file, but doing anything about it is non-trivial and low priority.
Re: hard typdef - proposal - I know it's not in the standard
On 23/01/13 08:55, Jonathan Wakely wrote: On 23 January 2013 06:53, Alec Teal wrote: Why not: make an "optional keyword", "hard", have a meaning if before "typedef", I suggest tokenising "hard" as a normal token (however it is processed now why change it? I am not sure on GCCs exact grammar for c languages) but if AND ONLY if it is before a "typdef" treat it differently, as far as I know a typedef can only occur at the beginning of a statement so this should mean it doesn't break anything. Like other specifiers such as const and static, typedef doesn't have to come first, i.e. this is legal, if unconventional: typedef int hard; hard typedef Int; I think Basile's suggestion to implement it as an attribute is a better idea, it makes it clearer it's something non-standard and compiler-specific, and the grammar already contains attributes in declarations. Problems: 1)Not all compilers would be happy with this. Fix: I'm sure gcc must define something for the preprocessor that'll exist if and only if GCC is the compiler? Nope, Compilers that claim GCC compatibility also define __GNUC__, and as has been discussed before on this list, if we added __REALLY_GCC__ then other compilers would just add that too. I was fearful of using the word attribute for fear of getting it wrong? What is "this part" of the compiler called (I'm doing this with gcc@gcc.gnu.org cced in for any future mes ;-))? Are there any decent-sized documents on it? I'd love a good read! Alec
Re: hard typdef - proposal - I know it's not in the standard
On 23 January 2013 09:15, Alec Teal wrote: > I was fearful of using the word attribute for fear of getting it wrong? What > is "this part" of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's "tree" data structures. FWIW I've usually seen this feature referred to as "strong typedefs". That brings to mind the "strong using" extension G++ had for namespaces, which (prior to getting standardised as "inline namespaces") used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html
Re: Compiling GCC problems
Hi, On Wed, Jan 23, 2013 at 08:16:43AM +, Alec Teal wrote: > configure went well but I keep hitting: > > ../.././gcc/gengtype.c:963: error: undefined reference to 'lexer_line' > ../.././gcc/gengtype.c:1098: error: undefined reference to 'lexer_line' > ../.././gcc/gengtype.c:1154: error: undefined reference to 'lexer_line' > ../.././gcc/gengtype.c:1164: error: undefined reference to 'lexer_line' > ../.././gcc/gengtype-parse.c:53: error: undefined reference to > 'yylex(char const**)' > ../.././gcc/gengtype-parse.c:1044: error: undefined reference to > 'yybegin(char const*)' > ../.././gcc/gengtype-parse.c:1070: error: undefined reference to > 'lexer_toplevel_done' > ../.././gcc/gengtype-parse.c:1075: error: undefined reference to 'yyend()' > > I've installed flex, bison and yacc (should it use it, it seems to > be using bison -y) (if I hadn't have installed flex would it's > "missing" ones have worked? > > What's wrong? It does configure fine! > I think that after you install flex you need to delete the build directory and start the configuration and build over again (or fixup something manually but I do not know what). Or at least I remember I had a very similar, if not the same, puzzling problem on one machine and that helped. Martin
Re: gcc : c++11 : full support : eta?
> I think we need to come out of the "documentation" mindset. No amount of > conventional documentation is going to help. What we need is a training > material that included well defined assignments. I agree. At one point, I had a large tutorial presentation. It's dated now, since it's before the tree-ssa era, but we definitely need something like that. High-quality documentation is critical, but isn't where people will be starting.
Better debugging with!
I've been thinking about this for a while and it can't hurt to share it
(it'd become shared eventually anyway) and someone might thing "good idea":
Obviously -g makes gcc embed a lot of information in the result that is
clear already why not that bit more? Arrays will always be integer sized
(4 bytes) (you could go long...) and it'd be really convenient if you
didn't have to tell gdb how big of an array to pretend it is, why not
tell it in code? This'd be great! It already knows about pointers so
this is just a simple step:
int n = 10;
#GDB_PAY_ATTENTION int n
MyType* arrayOfSorts = (MyType*) malloc(n*sizeof(MyType));
(not a word about calloc)
the int after ATTENTION is just if you had MASSIVE arrays beyond the
bounds of an unsigned int (could happen, who am I to prevent that, in
theory) perhaps int could be implicit, followed by the variable name or
constant size of the array.
This should just tell GDB to pay attention to the NEXT STATEMENT ONLY
and the first statement on that line (incase you can think of some weird
way this would mean re-writing something currently valid):
struct Vertex {
float x;
float y;
float z;
};
int n = 100*3;
#GDB_PAY_ATTENTION n
float* points = malloc(n*sizeof(float));
int k = n / 3;
#GDB_PAY_ATTENTION k
Vertex* vertices = (Vertex*) points;
Obviously not GDB_PAY_ATTENTION, that's supposed to be humour because I
have no ideas for a name yet.
I also see no reason not to allow "n" to be an expression? with the K
above an optimizer will have it's way with that anyway as k isn't used
after, you get the idea!
Alec
Re: gcc : c++11 : full support : eta?
On 23/01/13 10:26, Richard Kenner wrote: I think we need to come out of the "documentation" mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. I agree. At one point, I had a large tutorial presentation. It's dated now, since it's before the tree-ssa era, but we definitely need something like that. High-quality documentation is critical, but isn't where people will be starting. Please link it, I enjoy reading it and it couldn't harm!
Re: gcc : c++11 : full support : eta?
> Please link it, I enjoy reading it and it couldn't harm! I put it up at http://www.gnat.com/~kenner/gcctut.ppt It's 173 slides, but was last modified in 2000 and wasn't current then. It predates tree-ssa and many of the changes in the way that target macros were handled. But it does talk about: RTL RTL optimizers (though the older versions of some) Tree nodes and fields How to write a front end (though before function-at-a-time) How to port to a new machine
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 5:26 AM, Richard Kenner wrote: >> I think we need to come out of the "documentation" mindset. No amount of >> conventional documentation is going to help. What we need is a training >> material that included well defined assignments. > > I agree. At one point, I had a large tutorial presentation. It's dated > now, since it's before the tree-ssa era, but we definitely need something > like that. High-quality documentation is critical, but isn't where > people will be starting. Folks, we have a place for this material and I am constantly badgering people to use it. All the training material, courses, papers, presentations, pictures of design-on-a-napkin, are meant to be linked from http://gcc.gnu.org/wiki/GettingStarted. The wiki has become one of the most dynamic and best sources of such information in GCC. Let's use it! Uday, you have a wealth of experience organizing tutorials and such. Volunteers should not just be limited to code. Tutorials and courses are an excellent way to contribute. The steering committee has nothing to do with this. All they need to be involved in are administrivia matters with the FSF. No need to appoint volunteers, just start doing what you think is right. Organizing the GettingStarted wiki is a fantastic start. Diego.
Re: gcc : c++11 : full support : eta?
Uday Khedker writes: > I think we need to come out of the "documentation" mindset. No amount > of conventional documentation is going to help. What we need is a > training material that included well defined assignments. FWIW, I initially learned GCC by an internal training program Jeff Law devised over a decade ago (*). So perhaps there is some truth to the above statement. Of course, it didn't hurt that I had a cadre of good and patient maintainers willing to answer questions. [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. But anyways, that's just me. Different folk learn differently. Aldy (*) I think Alex Oliva was also a student of the Law training program :).
Re: Remove node from cgraph
On Mon, Jan 21, 2013 at 6:31 AM, Chassin wrote: > Hi ,i am developing a simple plugin that allows me to delete a node from the > cgraph that match a specific pattern but when i delete the node using > cgraph_remove_node , it seams to delete it ( by printing the cgraph again it > doesn't appear ) , but in the compiled file it exist my plugin is > attached to PLUGIN_ALL_PASSES_END event . can any one explain why this is > happening and what should i do to fix this issues ? The callgraph isn't the main data structure to modify here. You probably still have references to the function in the IL via calls for example. You probably want to remove all calls to the cgraph node. Richard. > Thnx in advance . > > -- > Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu > > Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’ > Informatics Engineering Faculty > > > > 48 Aniversario del Instituto Superior Politecnico Jose Antonio Echeverria, > Cujae > Una obra de la Revolucion Cubana | 2 de diciembre de 1964 | > http://cujae.edu.cu > > > > Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
Re: gcc : c++11 : full support : eta?
Alec Teal a écrit: > I'd love to help with GCC, without documentation (in fact, without > instructions) I have no hope of doing so. Maybe instruct/ask people to > do stuff? If I may propose something, I think a reasonable way of starting is to pick an (easy) bug from bugzilla and try to fix it. You can start with an internal compiler error that happens in a front end, for instance. Look at the code in the debugger from the point where it crashes. Step through it while compiling a simple test case to understand what it's doing. Oh, and do all that while having and IRC client not too far; connect to irc.oftc.net#gcc, and do not hesitate to ask people about parts of the code you don't understand. My experience here is that there are *many* people who are *very* friendly and willing to help in the GCC (I'd say GNU Tools in general) community. And hopefully, once you understand that part of the code that is precisely not well documented enough, you'll be able to propose patches to the documentation. You can also subscribe to bugzilla emails and try to reproduce the bugs people file, help reduce their test cases, triage (and comment on) the bugs. This task is utterly appreciated, and with time, that helps you get a better sense of how things are organized, and can provide you with an itch to scratch, so much that you'll start diving into some part of the code sooner than you'd have otherwise expected. Cheers, and please do not be impressed by the size of the code. Like for an elephant, I guess you can eat it one spoon at a time. -- Dodji
Re: gcc : c++11 : full support : eta?
I have been trying to do my stuff for a few years. We conduct a programme called "Essential Abstractions in GCC" which is aimed at taking a novice to a level from where she can do independent experimentation with GCC internals. I put together a bunch of teaching assistants (about 15 of them) for about 60 participants. Carefully designed programming assignments are an integral part of the training. The program ends with us summarizing the essential abstractions in 17 or 18 pictures with the hope that if one can understand the concepts represented by the pictures, one can walk the maze of the GCC code. You can find the details of the latest offering at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( Uday. Aldy Hernandez wrote, On Wednesday 23 January 2013 08:07 PM: Uday Khedker writes: I think we need to come out of the "documentation" mindset. No amount of conventional documentation is going to help. What we need is a training material that included well defined assignments. FWIW, I initially learned GCC by an internal training program Jeff Law devised over a decade ago (*). So perhaps there is some truth to the above statement. Of course, it didn't hurt that I had a cadre of good and patient maintainers willing to answer questions. [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. But anyways, that's just me. Different folk learn differently. Aldy (*) I think Alex Oliva was also a student of the Law training program :). -- signature.html Dr. Uday Khedker Professor Department of Computer Science & Engg. IIT Bombay, Powai, Mumbai 400 076, India. Email : u...@cse.iitb.ac.in Homepage: http://www.cse.iitb.ac.in/~uday Phone : Office -91 (22) 2572 2545 x 7717, 91 (22) 2576 7717 (Direct) Res. -91 (22) 2572 2545 x 8717, 91 (22) 2576 8717 (Direct)
Re: gcc : c++11 : full support : eta?
Uday Khedker wrote: > >I have been trying to do my stuff for a few years. We conduct a >programme called "Essential Abstractions in GCC" which is aimed at >taking a novice to a level from where she can do independent >experimentation with GCC internals. > >I put together a bunch of teaching assistants (about 15 of them) for >about 60 participants. Carefully designed programming assignments are >an >integral part of the training. The program ends with us summarizing the >essential abstractions in 17 or 18 pictures with the hope that if one >can understand the concepts represented by the pictures, one can walk >the maze of the GCC code. > >You can find the details of the latest offering at >http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. > >I would like to take this training program to the next level but so >long >it remains my personal baby, my funding agency does not feel that I >have >accomplished much because they feel that if my program has any merit, >the GCC community would adopt it :-( Can you hint at what they would consider adopting it? I suppose it is not simply linking to it from the wiki or the website? Richard. >Uday. > >Aldy Hernandez wrote, On Wednesday 23 January 2013 08:07 PM: >> Uday Khedker writes: >> >>> I think we need to come out of the "documentation" mindset. No >amount >>> of conventional documentation is going to help. What we need is a >>> training material that included well defined assignments. >> FWIW, I initially learned GCC by an internal training program Jeff >Law >> devised over a decade ago (*). So perhaps there is some truth to the >above >> statement. >> >> Of course, it didn't hurt that I had a cadre of good and patient >> maintainers willing to answer questions. >> >> [Before anybody asks, the training program is probably no longer >> relevant. So no fair bugging Jeff about it :)]. >> >> But anyways, that's just me. Different folk learn differently. >> >> Aldy >> >> (*) I think Alex Oliva was also a student of the Law training program >:).
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker wrote: > I would like to take this training program to the next level but so long > it remains my personal baby, my funding agency does not feel that I have > accomplished much because they feel that if my program has any merit, > the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Diego.
Re: gcc : c++11 : full support : eta?
On 23/01/13 19:05, Richard Biener wrote: Uday Khedker wrote: I have been trying to do my stuff for a few years. We conduct a programme called "Essential Abstractions in GCC" which is aimed at taking a novice to a level from where she can do independent experimentation with GCC internals. I put together a bunch of teaching assistants (about 15 of them) for about 60 participants. Carefully designed programming assignments are an integral part of the training. The program ends with us summarizing the essential abstractions in 17 or 18 pictures with the hope that if one can understand the concepts represented by the pictures, one can walk the maze of the GCC code. You can find the details of the latest offering at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( When I rule the world you will not have such problems. Seriously can you not reason with them? Can you hint at what they would consider adopting it? I suppose it is not simply linking to it from the wiki or the website? Richard. Uday. Aldy Hernandez wrote, On Wednesday 23 January 2013 08:07 PM: Uday Khedker writes: I think we need to come out of the "documentation" mindset. No amount This is being dragged up A LOT actually, and a lot of the clang-vs-gcc myths are just that, ALSO I was lead to believe GCC used some hand-coded stuff for final code output, one of the reasons I liked LLVM is because it seems sensible, I've just read a power-point presentation on RTL, GIMPLE cannot be a step back! Alec. of conventional documentation is going to help. What we need is a training material that included well defined assignments. FWIW, I initially learned GCC by an internal training program Jeff Law devised over a decade ago (*). So perhaps there is some truth to the above statement. Of course, it didn't hurt that I had a cadre of good and patient maintainers willing to answer questions. [Before anybody asks, the training program is probably no longer relevant. So no fair bugging Jeff about it :)]. But anyways, that's just me. Different folk learn differently. Aldy (*) I think Alex Oliva was also a student of the Law training program :). I just want to say you guys have been so nice! Totally not what I expected, so thanks for that!
Re: gcc : c++11 : full support : eta?
On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Uday.
Re: gcc : c++11 : full support : eta?
On 23/01/13 19:16, Uday Khedker wrote: On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Uday. I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. I know now that most of them were wrong BTW! Alec
Re: Remove node from cgraph
Please keep this on the list. On Wed, Jan 23, 2013 at 5:52 PM, Chassin wrote: > On 01/23/2013 10:55 AM, Richard Biener wrote: > > The callgraph isn't the main data structure to modify here. You probably > still > have references to the function in the IL via calls for example. You > probably > want to remove all calls to the cgraph node. > > Thanks for the quick replay Sr , do you mean by removing calls the ( edges ) > ? , but by using cgraph_remove_node it seams to delete all callee and > callers to that node > > > > 01494 cgraph_node_remove_callers (node); > 01495 cgraph_node_remove_callees (node); > 01496 ipa_remove_all_references (&node->ref_list); > 01497 ipa_remove_all_refering (&node->ref_list); > ... > > > in the dump file in my previous mail it shows that all edges related were > removed , should i remove the reference in the GIMPLE body manually ? how ? You need to remove the call stmts - they are the main representation of the edges which get re-built when needed. You can iterate over the call statements via the cgraph node callers list of edges. In the cgraph edge structure you'll find a call_stmt member. To remove it you need to switch to the corresponding function (push/pop_cfun, use DECL_STRUCT_FUNCTION (edge->caller->decl)) and then remove the stmt via for example gsi_remove () after initializing an iterator via gsi_for_stmt. That's not all of the details, you of course have to think of what to do for other references to the function (function pointers and later indirect calls). You have to think about what the point is of removing arbitrary calls throughout a program of course - I can't see any good reason to do this kind of stuff ;) Richard. > > cheers > > -- > Chaddy Huussin Vazquez , chas...@ceis.cujae.edu.cu > > Superior Polytechnic Institute ‘Jose Antonio Echeverrıa’ > Informatics Engineering Faculty > > 48 Aniversario del Instituto Superior Politécnico José Antonio Echeverría, > Cujae Una obra de la Revolución Cubana | 2 de diciembre de 1964 | > http://cujae.edu.cu > > > Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu
Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
[ We have drifted way off the original subject. ] On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker wrote: > Yes, absolutely. And GCC community should consider it important to bring in > newcomers particularly young students and experimenters from the academia. > > Why is it that most student projects these days are on LLVM and not on GCC? > Had these students been doing projects on GCC, some of them may turn > contributors in future. Yes. This is an issue for the long term viability of GCC as a project. In fact, I sometimes think that we may be past the tipping point. Note that the very set of developers that can fix these problems are, traditionally, the least likely to do much about it. These developers are already comfortable with the codebase, they know how to do the things they are hired to do and employers are largely on the same boat. Additionally, established developers will generally resist change, because these changes lead to short-term instability and bugs (the releng/maintainer mindset). Evolving this codebase is largely a thankless and difficult job. It's technically interesting to me, but I know I can only do so much. We have other demands on our time and often this conflicts with the nature of these changes. Some developers have done some work here and there to improve the codebase, but GCC's accumulated technical debt is large. If this trend continues, the pool of experienced GCC developers will eventually start to dwindle. Without developer renewal, GCC will naturally die out. This cycle has happened many times before and it will continue to happen. Yet, it would be interesting to have two or more strong competing open source compilers. The cross-pollination that open source competition encourages is beneficial to all (users and developers). Diego.
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 8:23 PM, Alec Teal wrote: > On 23/01/13 19:16, Uday Khedker wrote: >> >> >> >> >> >> On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: >>> >>> On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker >>> wrote: >>> I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( >>> >>> >>> I would say they have it backwards. The GCC community is the last one >>> who'd adopt such a training program. We already know the content! >>> >>> This kind of training is precisely targeted at newcomers. >> >> >> Yes, absolutely. And GCC community should consider it important to bring >> in newcomers particularly young students and experimenters from the >> academia. >> >> Why is it that most student projects these days are on LLVM and not on >> GCC? Had these students been doing projects on GCC, some of them may turn >> contributors in future. >> >> Uday. >> > I really have a theory here, I think (like me! I came here in the hope of > 'fixing' GCC from what I thought it was to what it is because I, suppose I > am loyal, I don't really like BSD, the lack of obligation to keep things > free, anyway that'll start a dispute probably so don't worry) it's all the > bad press, my impression was GCC is really old and archaic, not very good > for developing new optimisations, had a crap IR and there was this newcomer > that only made these problems known because it fixes them. > > I know now that most of them were wrong BTW! Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). Richard. > Alec >
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker wrote: > I would like to take this training program to the next level but so long > it remains my personal baby, my funding agency does not feel that I have > accomplished much because they feel that if my program has any merit, > the GCC community would adopt it :-( Uday, As Diego wrote, I am not sure what your funding agency thinks adoption would mean. Experienced GCC developers do not need to adopt your methodology to be productive. However, software developers who attend your workshops and classes should be able to engage the GCC community and contribute patches. Your centre needs to actively engage the GCC community and participate in development. The community does not always reward documentation activity as much as it should, but it also needs people to get involved and participate *in* the community on a regular basis, not work in parallel but distinct from the community. - David
Re: gcc : c++11 : full support : eta?
On 23/01/13 19:43, Richard Biener wrote: On Wed, Jan 23, 2013 at 8:23 PM, Alec Teal wrote: On 23/01/13 19:16, Uday Khedker wrote: On Thursday 24 January 2013 12:39 AM, Diego Novillo wrote: On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker wrote: I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( I would say they have it backwards. The GCC community is the last one who'd adopt such a training program. We already know the content! This kind of training is precisely targeted at newcomers. Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Uday. I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. I know now that most of them were wrong BTW! Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). Richard. You see my point though right? Alec
Re: Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
On Wed, Jan 23, 2013 at 8:38 PM, Diego Novillo wrote: > [ We have drifted way off the original subject. ] > > > On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker wrote: > >> Yes, absolutely. And GCC community should consider it important to bring in >> newcomers particularly young students and experimenters from the academia. >> >> Why is it that most student projects these days are on LLVM and not on GCC? >> Had these students been doing projects on GCC, some of them may turn >> contributors in future. > > Yes. This is an issue for the long term viability of GCC as a > project. In fact, I sometimes think that we may be past the tipping > point. > > Note that the very set of developers that can fix these problems are, > traditionally, the least likely to do much about it. These developers > are already comfortable with the codebase, they know how to do the > things they are hired to do and employers are largely on the same > boat. Additionally, established developers will generally resist > change, because these changes lead to short-term instability and bugs > (the releng/maintainer mindset). > > Evolving this codebase is largely a thankless and difficult job. It's > technically interesting to me, but I know I can only do so much. We > have other demands on our time and often this conflicts with the > nature of these changes. Some developers have done some work here and > there to improve the codebase, but GCC's accumulated technical debt is > large. > > If this trend continues, the pool of experienced GCC developers will > eventually start to dwindle. Without developer renewal, GCC will > naturally die out. This cycle has happened many times before and it > will continue to happen. Yet, it would be interesting to have two or > more strong competing open source compilers. The cross-pollination > that open source competition encourages is beneficial to all (users > and developers). Note that we can't drive GCC into the garage and refactor it for two years. Any refactoring done has to be while being live on the road! Which essentially limits on what kind of refactoring is possible - which also may limit the ultimate outcome of the sum of all refactorings. Always have this in mind before you turn GCC into an even greater mess than it is! The most important "refactoring" to a newcomer would IMHO be to further disentangle the already present components - both in the source tree structure as well as in separating (and moving together) of interfaces. Next easy part of that job is to create gcc/driver/ (gcc.c, collect2.c, etc.) and gcc/build/ (gen*.c). Then maybe add a getting-started section to the internals manual, eventually just pointing out external resources. Likewise refer to getting started material from contriubte.html which is where contributors will end up I suppose. Richard. > > Diego.
Re: Long term viability of GCC (was Re: gcc : c++11 : full support : eta?)
On 23/01/13 19:38, Diego Novillo wrote: [ We have drifted way off the original subject. ] On Wed, Jan 23, 2013 at 2:16 PM, Uday Khedker wrote: Yes, absolutely. And GCC community should consider it important to bring in newcomers particularly young students and experimenters from the academia. Why is it that most student projects these days are on LLVM and not on GCC? Had these students been doing projects on GCC, some of them may turn contributors in future. Yes. This is an issue for the long term viability of GCC as a project. In fact, I sometimes think that we may be past the tipping point. Note that the very set of developers that can fix these problems are, traditionally, the least likely to do much about it. These developers are already comfortable with the codebase, they know how to do the things they are hired to do and employers are largely on the same boat. Additionally, established developers will generally resist change, because these changes lead to short-term instability and bugs (the releng/maintainer mindset). Evolving this codebase is largely a thankless and difficult job. It's technically interesting to me, but I know I can only do so much. We have other demands on our time and often this conflicts with the nature of these changes. Some developers have done some work here and there to improve the codebase, but GCC's accumulated technical debt is large. If this trend continues, the pool of experienced GCC developers will eventually start to dwindle. Without developer renewal, GCC will naturally die out. This cycle has happened many times before and it will continue to happen. Yet, it would be interesting to have two or more strong competing open source compilers. The cross-pollination that open source competition encourages is beneficial to all (users and developers). Diego. As I am happy to be finding out though, even from RTL (old pdfs and stuff :)) GCC wasn't what I thought it was, to quote earlier: -- I really have a theory here, I think (like me! I came here in the hope of 'fixing' GCC from what I thought it was to what it is because I, suppose I am loyal, I don't really like BSD, the lack of obligation to keep things free, anyway that'll start a dispute probably so don't worry) it's all the bad press, my impression was GCC is really old and archaic, not very good for developing new optimisations, had a crap IR and there was this newcomer that only made these problems known because it fixes them. > I know now that most of them were wrong BTW! Ah, well - the old issue that LLVM has just become a very good marketing machinery (and we've stayed at being a compiler - heh). Richard. < You see my point though right? Alec -- Is it not just bad press? The articles perpetuate the "Wow look how easy clang is" which no one expects of GCC. Alec
Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0
Hi Richard, I am trying to understand the full implications of your statement: >> Yes, that's what I say. Any pointer that is dereferenced is first >> copied to >> an SSA name. Basically everything residing in memory first has to be >> loaded to an SSA name before it can be dereferenced. That load is >> explicit >> in the IL There are many parts and let me take one by one: - You talk about dereference. So a statement p=q would not mean loading q into memory. Had q been a global scalar variable, it would have been loaded into an SSA name. Then why is it not loaded when it is global pointer. Why a load only for p=*q and not for p=q? - When we have p=*q, agreed that we are loading a value from memory but then it is *q that is being loaded. Why should an SSA name be created for q even when q is a local pointer? What am I missing? Uday. On Friday 12 October 2012 03:25 PM, Uday P. Khedker wrote: Excellent! Thanks. Uday. Richard Biener wrote, On Friday 12 October 2012 03:20 PM: On Fri, Oct 12, 2012 at 11:46 AM, Uday P. Khedker wrote: Richard Biener wrote, On Friday 12 October 2012 02:51 PM: we _always_ see ssa_name_1 = a; use (ssa_name_1); so you have a place to associate your flow-sensitive and context-sensitive points-to-info with (the SSA name). My point is that for _using_ the points-to info flow-sensitivity provided by SSA form is enough. For computing it you of course need to flow-sensitively process assignments to 'a'. This is VERY interesting! I had not thought about the difference between computing and using values. Now that you point it out, I think all we need to do is to map flow-sensitively computed values to ssa names. What about variables that do not have ssa names? Or are you saying that all such variables would be copied into an artificial variables that have ssa names? I seem to observe this in the dumps but I don't know if it holds in general. Yes, that's what I say. Any pointer that is dereferenced is first copied to an SSA name. Basically everything residing in memory first has to be loaded to an SSA name before it can be dereferenced. That load is explicit in the IL so you should already compute points-to sets for the SSA name destination of the load. Richard. Uday.
Re: Fully flow and context sensitive points-to analysis in GCC 4.6.0
On Wed, Jan 23, 2013 at 8:12 PM, Uday Khedker wrote: > Hi Richard, > > I am trying to understand the full implications of your statement: > > >>> Yes, that's what I say. Any pointer that is dereferenced is first >>> copied to >>> an SSA name. Basically everything residing in memory first has to be >>> loaded to an SSA name before it can be dereferenced. That load is >>> explicit >>> in the IL > > There are many parts and let me take one by one: > > - You talk about dereference. So a statement p=q would not mean loading > q into memory. Had q been a global scalar variable, it would have been > loaded into an SSA name. Then why is it not loaded when it is global > pointer. Why a load only for p=*q and not for p=q? If q is a global pointer it is of course also first loaded into an SSA name. > - When we have p=*q, agreed that we are loading a value from memory but > then it is *q that is being loaded. Why should an SSA name be created > for q even when q is a local pointer? If q is a local pointer that does not have its address taken then it will be in SSA form. If it is not in SSA form then q is first loaded into an SSA name before it can be dereferenced. > > What am I missing? If I remember the discussion correctly it was about where to put points-to results. I said that fully flow-sensitive points-to info can be attached to SSA name definitions via SSA_NAME_PTR_INFO (as it is done now) and that this is the only place where we are looking at this information via the alias oracle. Because all indirect memory references - which are those with a non-trivial points-to set - happen through an SSA name pointer. The existing points-to solver of course keeps points-to sets for more things internally to be able to precisely deal with (sub-)memory objects. Internally it does so in a flow-insensitive way. At the end of the solving process all is translated to points-to solutions for the existing SSA name pointers in the program. Maybe that clarifies my answer - if not, can you re-phrase your question again? Thanks, Richard. > Uday. > > On Friday 12 October 2012 03:25 PM, Uday P. Khedker wrote: >> >> Excellent! Thanks. >> >> Uday. >> >> Richard Biener wrote, On Friday 12 October 2012 03:20 PM: >>> >>> On Fri, Oct 12, 2012 at 11:46 AM, Uday P. Khedker >>> wrote: Richard Biener wrote, On Friday 12 October 2012 02:51 PM: > > we _always_ see > > ssa_name_1 = a; > use (ssa_name_1); > > so you have a place to associate your flow-sensitive and > context-sensitive > points-to-info with (the SSA name). My point is that for _using_ the > points-to info flow-sensitivity provided by SSA form is enough. For > computing > it you of course need to flow-sensitively process assignments to 'a'. This is VERY interesting! I had not thought about the difference between computing and using values. Now that you point it out, I think all we need to do is to map flow-sensitively computed values to ssa names. What about variables that do not have ssa names? Or are you saying that all such variables would be copied into an artificial variables that have ssa names? I seem to observe this in the dumps but I don't know if it holds in general. >>> >>> >>> Yes, that's what I say. Any pointer that is dereferenced is first >>> copied to >>> an SSA name. Basically everything residing in memory first has to be >>> loaded to an SSA name before it can be dereferenced. That load is >>> explicit >>> in the IL so you should already compute points-to sets for the SSA name >>> destination of the load. >>> >>> Richard. >>> >>> Uday.
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 12:18 PM, Uday Khedker wrote: > I would like to take this training program to the next level but so long > it remains my personal baby, my funding agency does not feel that I have > accomplished much because they feel that if my program has any merit, > the GCC community would adopt it :-( With Gerald's recent approval, I have added an announcement of the IITB GCC Center to the News items on the GCC website front page. - David
Re: gcc : c++11 : full support : eta?
On Thursday 24 January 2013 12:35 AM, Richard Biener wrote: Uday Khedker wrote: I have been trying to do my stuff for a few years. We conduct a programme called "Essential Abstractions in GCC" which is aimed at taking a novice to a level from where she can do independent experimentation with GCC internals. I put together a bunch of teaching assistants (about 15 of them) for about 60 participants. Carefully designed programming assignments are an integral part of the training. The program ends with us summarizing the essential abstractions in 17 or 18 pictures with the hope that if one can understand the concepts represented by the pictures, one can walk the maze of the GCC code. You can find the details of the latest offering at http://www.cse.iitb.ac.in/grc/gcc-workshop-12/. I would like to take this training program to the next level but so long it remains my personal baby, my funding agency does not feel that I have accomplished much because they feel that if my program has any merit, the GCC community would adopt it :-( Can you hint at what they would consider adopting it? I suppose it is not simply linking to it from the wiki or the website? I know it sounds awkward but a government funding agency has its own notion of what is "official" and what is "not official". In their eyes, the GCC steering committee, the maintainers appointed by the steering committee etc. are official. All others are hobbyists :-) But on a serious note, it would be great to view the course material as more than documentation. The way there are "official" manuals and official code available on the gcc website (I can't have my own manual and call it GCC manual, or put up my code and call it GCC code), it would be good to have an official courseware. This is very different from putting it as one among so many other things on the wiki. Look at it from the view point of a newcomer. There are so many links and so many documents on the wiki that one does not even know where to begin from. Can we have ONE course for newcomers (of course refined based on the inputs from the developers) which the developers think represent their knowledge well enough for the newcomers? I don't mean to remove other material. We should have as much variety as possible but let there be one agreed upon starting point. After achieving some maturity, a person is not a newcomer and would be able to extract far more out of the other options that exist anyway. I will be very happy to take the responsibility of taking inputs and keep refining my material until we have something that we all feel is better than anything that we have had so far. That is what I mean by adoption of the training program. While I may not like what funding agency says, I do see a valid point in their expectations: They ask me "How have you influenced the GCC movement?". They are smart enough to know the difference between what I have done and whether the GCC community cares about it or not :-) Uday.
Re: gcc : c++11 : full support : eta?
On Wed, Jan 23, 2013 at 2:40 PM, Uday Khedker wrote: > This is very different from putting it as one among so many other things on > the wiki. Look at it from the view point of a newcomer. There are so many OK, then. Reorganize GettingStarted to make it prominent and advertise it. Move the other tutorials down below. Make it so a newcomer is not presented with an endless array of links. If something better comes along, then you duke it out with them. Simple as that. Diego.
Re: Bootstrapping glibc vs. dependency on system headers
As to the general case, I think float.h is probably the best choice and stdarg.h probably just as good. It's been a very long time since anything but GCC itself installed headers by those names. For libc, I think always using $CC -E is fine. You don't need to bother with the MSG_CHECKING and CACHE_VAL boilerplate. (Frankly I don't think it really matters to respect a user override of CPP, but ignoring one would be a somewhat more extreme departure from the norm.) It's best if comments refer to a URL in a bug database (libc's bugzilla or another one, whatever) with details filed there rather than pointing to a mailing list thread. If you do use URLs to mailing list archives, they must be to the canonical archive (http://sourceware.org/ml/libc-alpha/...) rather than to some third-party site. Thanks, Roland
Re: hard typdef - proposal - I know it's not in the standard
On 1/23/13, Jonathan Wakely wrote: > On 23 January 2013 09:15, Alec Teal wrote: >> I was fearful of using the word attribute for fear of getting it wrong? >> What >> is "this part" of the compiler called > > I think attributes are handled in the front end and transformed into > something in the compiler's "tree" data structures. > > FWIW I've usually seen this feature referred to as "strong typedefs". > That brings to mind the "strong using" extension G++ had for > namespaces, which (prior to getting standardised as "inline > namespaces") used __attribute__((strong)) so that attribute already > exists in the C++ front end: > http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html Note that there is a proposal before the C++ standard committee on just this topic. Consider its semantics when implementing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf -- Lawrence Crowl
GCC Plugin Announcement; CTraps - Lightweight dynamic analysis for concurrent code
Hi GCC list, I have implemented a GCC plugin that I have found useful for doing dynamic program analysis, debugging, and performance tuning in concurrent code. The plugin is called CTraps, short for Communication Traps. The main idea behind CTraps is that a compiler pass implemented as a GCC plugin instruments instructions that access memory locations that might be shared between threads. The instrumentation inserts a function call before such accesses. The CTraps runtime library implements the instrumentation function. It uses a "last writer table" to track the thread and instruction that last wrote to shared memory locations. When the program crashes, the last writer table is preserved in the core dump. If a threading bug is to blame for the failure, the last writer table can help diagnose it by revealing unintentional data sharing. In addition to maintaining the last writer table, CTraps exposes a plugin API that allows developers to implement their own plugins. Plugins can define functions that are called on every "communicating" instrumented memory access. An access is communicating if it accesses a memory location that the last writer table indicates was last written by an instruction in another thread. Using this plugin API, developers can implement concurrency debugging analyses, parallelism-aware performance profilers, and more. If you are interested in this project, check it out at https://github.com/blucia0a/CTraps-gcc Check out the included documentation for information on how to build, run, and extend CTraps. Feel free to email me with bug reports, questions, and comments about this work at blu...@gmail.com If you are interested in my other work on program analysis for finding and avoiding bugs in concurrent programs, visit my website: http://brandonlucia.com Thanks! -Brandon Lucia
Re: hard typdef - proposal - I know it's not in the standard
On 23/01/13 23:07, Lawrence Crowl wrote: On 1/23/13, Jonathan Wakely wrote: On 23 January 2013 09:15, Alec Teal wrote: I was fearful of using the word attribute for fear of getting it wrong? What is "this part" of the compiler called I think attributes are handled in the front end and transformed into something in the compiler's "tree" data structures. FWIW I've usually seen this feature referred to as "strong typedefs". That brings to mind the "strong using" extension G++ had for namespaces, which (prior to getting standardised as "inline namespaces") used __attribute__((strong)) so that attribute already exists in the C++ front end: http://gcc.gnu.org/onlinedocs/gcc/Namespace-Association.html Note that there is a proposal before the C++ standard committee on just this topic. Consider its semantics when implementing. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3515.pdf After reading that it doesn't seem like the same thing, they are talking about - essentially - creating "classes" to handle types with no runtime overhead, they want to be certain the optimizer got rid of it or save the optimizer a job. I'm not saying that's bad I just think it is separate. Typdefs are supposed to be an alias, yes in light of that the title of "type definition" seems a little misleading when put with that paper, but none the less a typedef is an alias. While reading the book "The design and evolution of C++" (I am not saying this to throw around "look, from the 'founder' of C++'s mouth!", I read it so I could learn why things are the way they are and errors which would have happened if things had of happened differently, wow that's a weird sentence, I mean failed attempts) I did enjoy reading about the strict typing that C++ introduced and that was to catch errors. The paper has a point, you would never try to multiply two game scores, so why have compiler tell you if you do? You'd surely mean it! What if you want to computer the geometric mean (or something, go with me) ultimately it's still an int! Why not go a step further and give the compiler the concept of a group (algebraic structure see [1]) this could stop divisions by zeros! Why not say you can no longer divide an integer by another integer? MOST of the time the result wont be an integer, with their example of cartesian(3) to spherical coordinates you shouldn't have to rigidly define such stuff that it throws an error when you do something as silly as mix them up and again, when they define x there is no one-size-fits-all definition for how x operates with other types. If you were to seriously try you'd just get so much spam, the only reason the idea doesn't totally implode is because you can "cast" back to the "base", so if all your definitions - which are more like conditions - don't allow something, you just side-step it, this is an own goal the point was you would never sidestep. There is a line between what I am proposing and what they are, I cannot define exactly where it is, by their own admitance they cant: /"This issue has been one of the consistent stumbling blocks in the design of an opaque typedef// //facility. In particular, we have come to realize that there is no one consistent approach to the// //return type issue such that it will meet all expectations under all circumstances//:"/ If they could this would be far more important than a proposed C++ feature and would have been 'discovered' during the Abstract Algebra boom during the times of Gauss. Back on topic! I always thought of a hard-typedef as an extension of this. I don't want it treated like a class, I don't want this to be valid: hard typdef int BookId; int x = 5; BookId my_book = x; //should fail BookId alternate = (BookId) x; //fine - no runtime overhead because it's just an alias, no compiling overhead really either. This (in the world of classes) is interesting because if anything int is the parent of BookId, but I shouldn't need a constructor or a reinterpret_cast (however it'd be applicable) because I had written "(BookId)" before the x, and that's probably not an accident the compiler should realize I meant to do it. Now what about the other way? hard typdef int BookId; BookId x = 5; int my_book = x; //should fail int alternate = (int) x; //fine - no runtime overhead because LOOK! Now in terms of inheritance we have it going both ways, so while you could look at this as typdef system as "a set of classes all storing one member of the same type with a different set of operations" you cannot have implicit conversions both ways! It just makes no sense, yes it can stop you writing stupid things anyway, but what use is there in defining "denominator" to be nonzero or what about composite types I would never want to multiply a real by an ima
A pass that worked in gcc-4.6.2 fails in gcc-4.7.2
Dear all,
I am currently updating a pass that was made for gcc-4.6.*, so that it
works for gcc.4.7.2.
In the pass for gcc-4.6.*, a code fragment from tree-ssa-structalias.c
was picked up and used.
Given below is the fragment taken form create_function_info_for () .
This fragment was used to create variable information for the function
and it was picked up to perform a similar operation in the added pass
as well.
But in gcc-4.7.2 some changes are introduced in the fragment. The code
given below shows the changes that have been introduced in
create_function_info_for () of tree-ssa-structalias.c in gcc-4.7.2
along with the original code in the comments.
/* Add one representative for all further args. */
if (is_varargs)
{
varinfo_t argvi;
const char *newname;
char *tempname;
tree decl;
asprintf (&tempname, "%s.varargs", name);
newname = ggc_strdup (tempname);
free (tempname);
/* We need sth that can be pointed to for va_start. */
/ CHANGED CODE in GCC-4.7.2 ***/
decl = build_fake_var_decl (ptr_type_node);
/ ORIGINAL CODE in GCC-4.6.2 ***
/* decl = create_tmp_var_raw (ptr_type_node, name);
get_var_ann (decl);
*/
argvi = new_var_info (decl, newname);
argvi->offset = fi_parm_base + num_args;
argvi->size = ~0;
argvi->is_full_var = true;
argvi->is_heap_var = true;
argvi->fullsize = vi->fullsize;
gcc_assert (prev_vi->offset < argvi->offset);
prev_vi->next = argvi;
prev_vi = argvi;
}
return vi;
So I made the same changes in the pass where this fragment was used.
But after making the changes the pass is now giving an "internal
compiler error" and a "segmentation fault" at runtime.
After debugging I could narrow it down to the function
build_fake_var_decl() and to be specific at the memory allocation
statement highlighted below.
tree
build_fake_var_decl (tree type)
{
/ My debugging showed that the control came
here */
tree decl = (tree) XOBNEW (&fake_var_decl_obstack, struct tree_var_decl);
/ But did not come here
**/
memset (decl, 0, sizeof (struct tree_var_decl));
TREE_SET_CODE (decl, VAR_DECL);
TREE_TYPE (decl) = type;
DECL_UID (decl) = allocate_decl_uid ();
SET_DECL_PT_UID (decl, -1);
layout_decl (decl, 0);
return decl;
}
The builf_fake_var_decl() function is a gcc function defined in
tree-ssa-structalias.c. To be able to use it in my pass, I removed the
keyword static in its definition.
I cannot figure out what can possibly cause this error in the XOBNEW function.
Please help!!!
Sudakshina Das
