Re: [RFC] Full float128, third iteration
Il 11/09/2010 1.42, Steve Kargl ha scritto: On Sat, Sep 11, 2010 at 01:05:23AM +0200, Angelo Graziosi wrote: Il 10/09/2010 19.31, Steve Kargl ha scritto: The ideal solution would be incorporating libquad into libgfortran The ideal solution would be building GCC enabling QP with ./configure... --enable-quad if the system allow for QP: in this case, perhaps, QP should be enabled by default. Well, in my ideal world :-), you would not have a --enable-quad option. If __float128 is supported, then you get REAL(16). Perhaps the same thought :-). Re-read with #define QP __float128 Ciao, Angelo.
Re: [RFC] Full float128, third iteration
* FX wrote on Fri, Sep 10, 2010 at 07:08:10PM CEST: > I'm CC'ing the gcc list so I can get insight from people who > understand correctly how static libraries should be handled by the > driver... > > > I'm seeing a similar issue with -static linkage. > > > > % gfc4x -o z norm2_3.f90 -L/usr/home/sgk/work/lib -lquad -static > > OK, I see the same thing. It's due to the fact that when you call: > > gfortran mycode.f90 -lquad -static > > the linker is called with the following order for the libraries: > > -lquad -lgfortran -lm --start-group -lgcc -lgcc_eh -lc --end-group > > while libgfortran depends on libquad, so it should be "-lgfortran -lquad". > > I'm not very knowledgeable about that, but I think what we can have > the driver recognized "-lquad" and move it after "-lgfortran". That > won't handle all cases (what if libquad is called something else on > your computer? what if you link to a specific version, -lquad1.0? what > if you link directly by specifying the archive file, > /path/to/libquad.a?) I don't think you should move it. Just make sure that it *also* appears after -lgfortran if you need that. Specifying libraries more than once is not uncommon, when static libraries are involved. One exception to the above technique is when there are weird symbol override games to be played between shared libquad and libgfortran (which I don't think is the case). Cheers, Ralf
RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
> I kind of suspect it might be a type mismatch, overwriting part of a tree node configure -enable-checking: ?"Bmr?: In function 'FPrint__xCombine': `?"Bmr?:13:0: internal compiler error: tree check: expected ssa_name, have var_decl in copy_phis_for_bb, at tree-inline.c:1950 and some other problems..I really need to fix those... - Jay > From: jay.kr...@cornell.edu > To: i...@google.com > CC: gcc@gcc.gnu.org > Subject: RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c > Date: Fri, 10 Sep 2010 20:38:58 + > > > [licensing dealt with separately] > > > > > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def > > > 0x412130a8 1093058884 > > This is clearly wrong, though I have no idea what caused it. > > > Is it valid for uids to be so high? > > No. > > Thanks, that helps. > > > > From your description, you've implemented some sort of customized tree > > reader. > > > Not exactly, by my understanding of terminology. > We do end up making gcc trees but we serialize something that is separately > specified and not really the same, though some level of resemblance is > unavoidable since they both are involved with compilation, i.e. they both > have operations like "add" and notions of locals, parameters, functions, etc. > Ours is stack-based though for example (not my preference, but it was already > there). > > > > Does it play nicely with the garbage collector? > > > I think so. > We have the GTY annotations, I've managed to crash things when I got them > wrong/missing. I haven't moved all targets from 4.3.x to 4.5.x so I even have > to hack on the code a bit because GTY has to be in a different place. > I put the type declarations in seperate .h files, maintain both, and copy one > over the other before compilation. > > > We do have an open bug report about causing the gcc garbage collector > consuming infinite memory, maybe due to a cycle in our data. > But really the system works a ton. I can compile and run tens of thousands of > lines > of code, for multiple architectures. I "just" have to turn off inlining, and > a small number of other optimizations. Clearly we are pretty good, and flawed. > > > Notice that the gcc middle end seemed to have created this variable with the > high uid. > I checked the globals that guide uid assignment, found them after sending the > first mail. They aren't so high. > I haven't yet found where this uid comes from. > I kind of suspect it might be a type mismatch, overwriting part of a tree node > with the wrong type or such. > I'll have to dig more. > > I know it comes from here: > copy_phis_for_bb: > ... > SSA_NAME_DEF_STMT (new_res) > = new_phi = create_phi_node (new_res, new_bb); > > > > Thanks, > - Jay >
RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
arg..well, I had replaced xmalloc with alloca, leading to some of the garbage
below, but
I am indeed still running afoul of the garbage collector.
I don't know if that is my original problem but I should probably fix this
first.
ie: now that I'm using -enable-checking, and I think it collects earlier/more
often.
I need to "map" my internal unsigned long arbitrary integers, to trees.
So I just have an array of struct {unsigned id; tree t };
I put GTY on the struct, on the field, and on the VEC of them.
When I append I mark it dirty.
When I search I qsort if dirty, then bsearch.
typedef struct GTY(()) m3type_t
{
unsigned long id;
tree GTY (()) t;
} m3type_t;
static GTY (()) VEC (m3type_t,gc)* m3type_table;
seems reasonable eh?
The files are in gtfiles. When I put the GTY in the wrong place I get compile
errors.
I guess I can try rolling my own "VEC" or even use a fixed size and see what
happens..
Thanks,
- Jay
> From: jay.kr...@cornell.edu
> To: i...@google.com
> CC: gcc@gcc.gnu.org
> Subject: RE: internal compiler error: in referenced_var_lookup, at tree-dfa.c
> Date: Sat, 11 Sep 2010 08:48:08 +
>
>
> > I kind of suspect it might be a type mismatch, overwriting part of a tree
> > node
>
> configure -enable-checking:
>
> ?"Bmr?: In function 'FPrint__xCombine':
> `?"Bmr?:13:0: internal compiler error: tree check: expected ssa_name, have
> var_decl in copy_phis_for_bb, at tree-inline.c:1950
>
> and some other problems..I really need to fix those...
>
> - Jay
>
>
> > From: jay.kr...@cornell.edu
> > To: i...@google.com
> > CC: gcc@gcc.gnu.org
> > Subject: RE: internal compiler error: in referenced_var_lookup, at
> > tree-dfa.c
> > Date: Fri, 10 Sep 2010 20:38:58 +
> >
> >
> > [licensing dealt with separately]
> >
> >
> >
> > > > Variable: D.1093058884, UID D.1093058884, int_32gimple_default_def
> > > > 0x412130a8 1093058884
> > > This is clearly wrong, though I have no idea what caused it.
> > > > Is it valid for uids to be so high?
> > > No.
> >
> > Thanks, that helps.
> >
> >
> > > From your description, you've implemented some sort of customized tree
> > > reader.
> >
> >
> > Not exactly, by my understanding of terminology.
> > We do end up making gcc trees but we serialize something that is separately
> > specified and not really the same, though some level of resemblance is
> > unavoidable since they both are involved with compilation, i.e. they both
> > have operations like "add" and notions of locals, parameters, functions,
> > etc.
> > Ours is stack-based though for example (not my preference, but it was
> > already there).
> >
> >
> > > Does it play nicely with the garbage collector?
> >
> >
> > I think so.
> > We have the GTY annotations, I've managed to crash things when I got them
> > wrong/missing. I haven't moved all targets from 4.3.x to 4.5.x so I even
> > have
> > to hack on the code a bit because GTY has to be in a different place.
> > I put the type declarations in seperate .h files, maintain both, and copy
> > one
> > over the other before compilation.
> >
> >
> > We do have an open bug report about causing the gcc garbage collector
> > consuming infinite memory, maybe due to a cycle in our data.
> > But really the system works a ton. I can compile and run tens of thousands
> > of lines
> > of code, for multiple architectures. I "just" have to turn off inlining, and
> > a small number of other optimizations. Clearly we are pretty good, and
> > flawed.
> >
> >
> > Notice that the gcc middle end seemed to have created this variable with
> > the high uid.
> > I checked the globals that guide uid assignment, found them after sending
> > the
> > first mail. They aren't so high.
> > I haven't yet found where this uid comes from.
> > I kind of suspect it might be a type mismatch, overwriting part of a tree
> > node
> > with the wrong type or such.
> > I'll have to dig more.
> >
> > I know it comes from here:
> > copy_phis_for_bb:
> > ...
> > SSA_NAME_DEF_STMT (new_res)
> > = new_phi = create_phi_node (new_res, new_bb);
> >
> >
> >
> > Thanks,
> > - Jay
> >
>
Re: Merging Apple's Objective-C 2.0 compiler changes
> Well, the words on their distribution say exactly this: > > GCC is free software; you can redistribute it and/or modify it under > the terms of the GNU General Public License as published by the Free > Software Foundation; either version 2, or (at your option) any later > version. > > That means, we at our option can choose to release under GPL v3, > exclusively, if we wanted. I disagree, as I said. My interpretation of that sentence is that "when you redistribute this, you must give the person you redistribute it to the right to further redistribute it under EITHER GPLv2 OR GPLv3". Giving somebody the right to only redistribute under GPLv3 does NOT satisfy that requirement.
'Range-based for' support for gcc
Hello.
It is a great effort to implement 'range-based for' in gcc 4.6. But it
could be interesting for you what recent C++0x standard draft (N3126)
contains some significant change for this feature:
--- begin quote --
6.5.4 The range-based for statement [stmt.ranged]
1 The For a range-based for statement of the form
for ( for-range-declaration : expression ) statement
let range-init be equivalent to the expression surrounded by parentheses:
( expression )
and for a range-based for statement of the form
for ( for-range-declaration : braced-init-list ) statement
let range-init be equivalent to the braced-init-list.
--- end quote --
which allows to use following construction:
for (auto i: {1, 2, 3, 4, 5})
{
std::cout << i << " ";
}
--
Best Regards,
Flex mailto:flex_fer...@artberg.ru
Re: 'Range-based for' support for gcc
On 09/11/2010 08:08 PM, Flex Ferrum wrote:
> for (auto i: {1, 2, 3, 4, 5})
> {
> std::cout << i << " ";
> }
>
It works fine already, see also the new testcase range-for6.C. Unless
you mean something else entirely and I'm not getting your point...
Paolo.
Re: RFH: optabs code in the java front end
On 09/10/2010 11:50 PM, Steven Bosscher wrote:
> There is just one front-end file left that still has to #undef
> IN_GCC_FRONTEND, allowing the front end to include RTL headers. The
> one remaining file is java/builtins.c.
>
> In java/builtins.c there are (what appear to be) functions that
> generate code for Java builtins, and these functions look at optabs to
> decide what to emit. For example:
>
> static tree
> compareAndSwapInt_builtin (tree method_return_type ATTRIBUTE_UNUSED,
>tree orig_call)
> {
> enum machine_mode mode = TYPE_MODE (int_type_node);
> if (direct_optab_handler (sync_compare_and_swap_optab, mode)
> != CODE_FOR_nothing
> || flag_use_atomic_builtins)
> {
> tree addr, stmt;
>
>
> As a result, java/builtins.c has to include most RTL-specific headers:
>
> /* FIXME: All these headers are necessary for sync_compare_and_swap.
>Front ends should never have to look at that. */
> #include "rtl.h"
> #include "insn-codes.h"
> #include "expr.h"
> #include "optabs.h"
>
> I would really like to see this go away, and I would work on it if I
> had any idea what to do.
The test tells us whether the back-end has atomic builtins. If it doesn't
then we generate calls to the libgcj back end. I really don't want gcj
to generate calls to nonexistent __compare_and_swap_4 or somesuch.
> I thought that the builtins java/builtins.c
> adds here, are generic GCC builtins. For example there is a definition
> of BUILT_IN_BOOL_COMPARE_AND_SWAP_4 in sync-builtins.def, so what is
> the effect of the
> "define_builtin(BUILT_IN_BOOL_COMPARE_AND_SWAP_4,...)" code in
> java/builtins.c:initialize_builtins? Does this re-define the builtin?
> I don't understand how the front-end definition of the builtin and the
> one from sync-builtins.def work together.
Well, the ones from sync-builtins.def have different names: otherwise
they're the same as the Java ones.
Andrew.
Re: RFH: optabs code in the java front end
On Sat, Sep 11, 2010 at 8:48 PM, Andrew Haley wrote:
> On 09/10/2010 11:50 PM, Steven Bosscher wrote:
>
>> There is just one front-end file left that still has to #undef
>> IN_GCC_FRONTEND, allowing the front end to include RTL headers. The
>> one remaining file is java/builtins.c.
>>
>> In java/builtins.c there are (what appear to be) functions that
>> generate code for Java builtins, and these functions look at optabs to
>> decide what to emit. For example:
>>
>> static tree
>> compareAndSwapInt_builtin (tree method_return_type ATTRIBUTE_UNUSED,
>> tree orig_call)
>> {
>> enum machine_mode mode = TYPE_MODE (int_type_node);
>> if (direct_optab_handler (sync_compare_and_swap_optab, mode)
>> != CODE_FOR_nothing
>> || flag_use_atomic_builtins)
>> {
>> tree addr, stmt;
>>
>>
>> As a result, java/builtins.c has to include most RTL-specific headers:
>>
>> /* FIXME: All these headers are necessary for sync_compare_and_swap.
>> Front ends should never have to look at that. */
>> #include "rtl.h"
>> #include "insn-codes.h"
>> #include "expr.h"
>> #include "optabs.h"
>>
>> I would really like to see this go away, and I would work on it if I
>> had any idea what to do.
>
> The test tells us whether the back-end has atomic builtins. If it doesn't
> then we generate calls to the libgcj back end. I really don't want gcj
> to generate calls to nonexistent __compare_and_swap_4 or somesuch.
>
>> I thought that the builtins java/builtins.c
>> adds here, are generic GCC builtins. For example there is a definition
>> of BUILT_IN_BOOL_COMPARE_AND_SWAP_4 in sync-builtins.def, so what is
>> the effect of the
>> "define_builtin(BUILT_IN_BOOL_COMPARE_AND_SWAP_4,...)" code in
>> java/builtins.c:initialize_builtins? Does this re-define the builtin?
>> I don't understand how the front-end definition of the builtin and the
>> one from sync-builtins.def work together.
>
> Well, the ones from sync-builtins.def have different names: otherwise
> they're the same as the Java ones.
So why can't these be called instead of the Java ones? I suppose there
are libgcc versions?
Ciao!
Steven
Re: RFH: optabs code in the java front end
On Sat, 11 Sep 2010, Andrew Haley wrote: > The test tells us whether the back-end has atomic builtins. If it doesn't > then we generate calls to the libgcj back end. I really don't want gcj > to generate calls to nonexistent __compare_and_swap_4 or somesuch. Maybe not to nonexistent functions, but if the functions exist - say the kernel-assisted libgcc functions used on Linux on SH, PA and older ARM processors - then certainly they should be used. So optabs are hardly the right thing to check; if you need to know whether this functionality is supported, you need a hook that will say whether there is a library fallback when code for __sync_* isn't generated inline. -- Joseph S. Myers jos...@codesourcery.com
Re: Merging Apple's Objective-C 2.0 compiler changes
Hello, * Richard Kenner wrote on Sat, Sep 11, 2010 at 01:18:10PM CEST: > > That means, we at our option can choose to release under GPL v3, > > exclusively, if we wanted. > > I disagree, as I said. > > My interpretation of that sentence is that "when you redistribute > this, you must give the person you redistribute it to the right to > further redistribute it under EITHER GPLv2 OR GPLv3". Giving somebody > the right to only redistribute under GPLv3 does NOT satisfy that > requirement. Please ask the FSF legal dept. to clarify the situation once and for all, they should be able to provide you with a binding (as for GCC) answer within a short time frame. This topic has come up on this list before, without obvious agreement from all parties afterwards, and is mostly off-topic here. Thank you, Ralf
Get of them. Jefferies had heard
Fice of cook, the duties of which he was far better able to perform than any of the English. The French lieutenant seemed the most cast-down of any of the party. He sat by himself not speaking to any one, and with an air of discontent, put away the food which was brought to him. "The poor lieutenant mourns and seems very unhappy," said David to Pierre. "Yes," answered Pierre, "he is often thus morose when anything ann <>
Re: Merging Apple's Objective-C 2.0 compiler changes
> Please ask the FSF legal dept. to clarify the situation once and for > all, they should be able to provide you with a binding (as for GCC) > answer within a short time frame. It's my understanding that FSF legal department has consistently refused to answer such questions as this.
Re: Merging Apple's Objective-C 2.0 compiler changes
* Richard Kenner wrote on Sat, Sep 11, 2010 at 11:01:56PM CEST: > > Please ask the FSF legal dept. to clarify the situation once and for > > all, they should be able to provide you with a binding (as for GCC) > > answer within a short time frame. > > It's my understanding that FSF legal department has consistently refused > to answer such questions as this. Do you have a quote for that, please? I remember otherwise, but only from conversation. Thanks, Ralf
Re: Merging Apple's Objective-C 2.0 compiler changes
> > It's my understanding that FSF legal department has consistently refused > > to answer such questions as this. > > Do you have a quote for that, please? How do you quote somebody who DOESN'T answer? The FSF has consistently refused to answer questions of the form "if I did XYZ, would it violate the GPL?" And I agree with that policy. (Note that this doesn't mean that the FSF doesn't have opinions about what maintainers of GNU software should do, but those are matters of POLICY, not saying "if you don't do that, you'll violate the GPL".)
gcc-4.6-20100911 is now available
Snapshot gcc-4.6-20100911 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20100911/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 164217 You'll find: gcc-4.6-20100911.tar.bz2 Complete GCC (includes all of below) MD5=e8b3ba3699abf846986d79bc3c84e7ee SHA1=c59788876ce78d699603ba99888f69b9eb8ea085 gcc-core-4.6-20100911.tar.bz2C front end and core compiler MD5=e43129007d571c17b3ba9f1d6d017670 SHA1=390a196549319fcedb76e2b16ab65af9c2dcbb96 gcc-ada-4.6-20100911.tar.bz2 Ada front end and runtime MD5=da22c0809c22f5b33b3e0b06c9acb51e SHA1=716be4ebf212faeb6102f0209a9b44a56f56f238 gcc-fortran-4.6-20100911.tar.bz2 Fortran front end and runtime MD5=4be816694527dbbab31cb5d8af0b1432 SHA1=02c0aa3e8e44969a6603e03ea9a8df8eb1cdd829 gcc-g++-4.6-20100911.tar.bz2 C++ front end and runtime MD5=5e8aa0e925a32e52e30b0ab535998ce2 SHA1=d415f84714c40be8d649bce99e2b40de4e5becb4 gcc-java-4.6-20100911.tar.bz2Java front end and runtime MD5=521537ff2cbfd554228ec5e9037abc28 SHA1=29ab8f04d4173c034934092061b32829f246ee69 gcc-objc-4.6-20100911.tar.bz2Objective-C front end and runtime MD5=ee211fa3fc6e11e1a5a7bcc6be66e8ef SHA1=8d2803d34d9906a063b481d91c8158e481fab0af gcc-testsuite-4.6-20100911.tar.bz2 The GCC testsuite MD5=816e7128ef51d4f3f77e315caf4da365 SHA1=47a7d412f9d0ff32e94fd4f493ffe968146c81dc Diffs from 4.6-20100904 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.6 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.
How to parse a code snippet at front-end plugin
Hi,
I am try to make a plugin to analyze GIMPLE before genericize. It
will insert some code defined by user into the tree. I want the user
to specify the inserted code in C. For example,
--
{
static int i=0;
printf("Hello %d\n", i++);
}
--
I try to find a way to make C language parser of GCC to compile it for
me, and I will insert the code into the tree created from the main
source. But, it seems provide only functions to parse a complete C
source file, and I try to push a buffer to the reader of libcpp. But,
it does not work.
Does C parser of GCC provide any way to parse a file or a snippet of
code. Should I modify the source of c-parser.c to export new
functions by my-self!?
Re: Merging Apple's Objective-C 2.0 compiler changes
On Sat, Sep 11, 2010 at 06:17:47PM -0400, Richard Kenner wrote: > > > It's my understanding that FSF legal department has consistently refused > > > to answer such questions as this. > > > > Do you have a quote for that, please? > > How do you quote somebody who DOESN'T answer? > > The FSF has consistently refused to answer questions of the form "if I did > XYZ, would it violate the GPL?" And I agree with that policy. > > (Note that this doesn't mean that the FSF doesn't have opinions about > what maintainers of GNU software should do, but those are matters of > POLICY, not saying "if you don't do that, you'll violate the GPL".) Alternatively, perhaps Apple could clarify their own license file to clearly indicate that they do not prohibit their GPLv2 code from being relicensed as GPLv3-only code. After all, this doesn't really change the licensing status of Apple's changes in their gcc sources as they stay at GPLv2. Jack ps What examples are there of projects with GPLv3 licenses which aren't GPLv3 only (and allow code to be relicensed back as GPLv2)?
Re: question on points-to analysis
On Thu, Sep 9, 2010 at 7:24 AM, Richard Guenther wrote: > On Thu, Sep 9, 2010 at 1:19 PM, Amker.Cheng wrote: >> Hi, >> I am studying gcc's points-to analysis right now and encountered a question. >> In paper "Off-line Variable Substitution for Scaling Points-to >> Analysis", section 3.2 >> It says that we should not substitute a variable with other if it is >> taken address. > and How gcc keeps accuracy of points-to >> information after doing this. In theory, this is true, but a lot of the optimizations decrease accuracy at a cost of making the problem solvable in a reasonable amount of time. By performing it after building initial points-to sets, the amount of accuracy loss is incredibly small. The only type of constraint that will generate inaccuracy at that point is a complex address taken with offset one, which is pretty rare. On the other hand, *not* doing it will make the problem take forever to solve :) What's better, something that gives correct but slightly conservative answers in 10s, or something that gives correct and 1% less conservative answers in 200s?
Re: question on points-to analysis
> In theory, this is true, but a lot of the optimizations decrease > accuracy at a cost of making the problem solvable in a reasonable > amount of time. > By performing it after building initial points-to sets, the amount of > accuracy loss is incredibly small. > The only type of constraint that will generate inaccuracy at that > point is a complex address taken with offset one, which is pretty > rare. > On the other hand, *not* doing it will make the problem take forever to solve > :) > > What's better, something that gives correct but slightly conservative > answers in 10s, or something that gives correct and 1% less > conservative answers in 200s? > Got it, Thanks for Richard's quick reply and Daniel's detailed explanation. I need to dig deep to understand the codes. -- Best Regards.
Re: Merging Apple's Objective-C 2.0 compiler changes
On 11/09/2010 23:17, Richard Kenner wrote: >>> It's my understanding that FSF legal department has consistently refused >>> to answer such questions as this. >> Do you have a quote for that, please? > > How do you quote somebody who DOESN'T answer? By using a null string, of course! cheers, DaveK
Re: Merging Apple's Objective-C 2.0 compiler changes
* Richard Kenner wrote on Sun, Sep 12, 2010 at 12:17:47AM CEST: > > > It's my understanding that FSF legal department has consistently refused > > > to answer such questions as this. > > > > Do you have a quote for that, please? > > How do you quote somebody who DOESN'T answer? I've asked for you now. > The FSF has consistently refused to answer questions of the form "if I did > XYZ, would it violate the GPL?" Maybe, but this is such a simple question that I'm sure the GPL meant to address unambiguously, that I think it is worth trying to stop spreading uncertainty over. Cheers, Ralf
Re: How to parse a code snippet at front-end plugin
On Sat, 11 Sep 2010 22:19:06 +0800 (CST)
"Thinker K.F. Li" wrote:
> Hi,
>
> I am try to make a plugin to analyze GIMPLE before genericize. It
> will insert some code defined by user into the tree. I want the user
> to specify the inserted code in C. For example,
>
> --
> {
> static int i=0;
>
> printf("Hello %d\n", i++);
> }
> --
>
> I try to find a way to make C language parser of GCC to compile it for
> me, and I will insert the code into the tree created from the main
> source. But, it seems provide only functions to parse a complete C
> source file, and I try to push a buffer to the reader of libcpp. But,
> it does not work.
I am not sure that there exist enough plugin hooks to do that (I am not sure
even if there are plugin hooks to front-ends in GCC). However, I do see some
way to perhaps implement what you suggest even in 4.5
First, don't think of your problem as adding C code. Think of it as adding
Gimple stuff into some Gimple representation.
(I believe it is a case of aspect oriented programming, see
http://en.wikipedia.org/wiki/Aspect-oriented_programming for more). But you
want the user to specify the added code, using the already accepted C syntax of
GCC (i.e. without hacking GCC parser).
So you could use attributes & pragmas or builtins for that purpose.
First, your user define its code snipped to insert as a C function with a
special attribute, e.g.
void say_hello(void) __attribute__((added_chunk));
void say_hello(void)
{
static int i;
printf("Hello %d\n", i++);
}
Then, your user would mark with another attribute every function into which
your chunk should be added, perhaps
int some_complex_function(int a, void*b)
__attribute((insert_chunk(say_hello)));
Or perhaps have a pragram asking this to insert the chunk in every function
whose name start with some_
#pragma GCCMELT insert_chunk_prefix(say_hello, some_)
The point here is that with the tricks above, you don't have to change GCC
parser! and you could implement that using a plugin coded in C (this is not so
simple, you have to filter Gimple). Better yet, you could implement that using
GCC MELT http://gcc.gnu.org/wiki/MELT which provides pattern matching
facilities on Gimple to make such tasks much simpler.
You still have to understand Gimple & Tree in detail and find a good position
in the pass machinery to insert your new pass or passes.
If you succeed in making such a plugin please tell us. I would be delighted if
you coded it in MELT, as a MELT extension.
Good luck.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
