| Message ID | 52814709.6080904@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Nov 11, 2013 at 10:07 PM, Andrew MacLeod <amacleod@redhat.com> wrote: > This one covers the front end files which included gimple.h > > Bootstraps on x86_64-unknown-linux-gnu with no new regressions. OK? * c-family/c-omp.c: Include gimple-expr.h instead of gimple.h. can you explain why gimple-expr.h is not as bad as gimple.h? (gimple-expr.h sounds oxymoronish ... but I didn't follow the thread that ended up creating this beast, it seems a better matching name would be gimple-tree.h ... haha). Otherwise gimple.h -> gimplify.h indeed looks like an improvement. Thanks, Richard. > Andrew
On 11/13/2013 04:40 AM, Richard Biener wrote: > On Mon, Nov 11, 2013 at 10:07 PM, Andrew MacLeod <amacleod@redhat.com> wrote: >> This one covers the front end files which included gimple.h >> >> Bootstraps on x86_64-unknown-linux-gnu with no new regressions. OK? > * c-family/c-omp.c: Include gimple-expr.h instead of gimple.h. > > can you explain why gimple-expr.h is not as bad as gimple.h? > (gimple-expr.h sounds oxymoronish ... but I didn't follow the thread > that ended up creating this beast, it seems a better matching name > would be gimple-tree.h ... haha). > > Otherwise gimple.h -> gimplify.h indeed looks like an improvement. > > There needs to be a place which has gimple componentry that is not related to or require a statement. gimple.h is becoming the home for just 0gimple statements. There are 3 (for the moment) major classes of things that are in statements and are also used by other parts of the compiler .. Types, Decls, and Expressions. I could have split it into those 3 files right now, but it didn't seem like that granularity was needed yet. I was going to call it gimple-decl.h since most of the things are decl related... but I figured that eventually there will be all 3 files, and its likely that gimple-expr.h will eventually include gimple-type.h and gimple-decl.,h so just include gimple-expr.h now and have less include turmoil eventually. Perhaps that wont be the case and gimple-decl.h may have been a more appropriate name for now. Its true that gimple-tree would in fact be a more appropriate name at the moment, but these gimple-* files are the core ones I'll be changing first, so the tree part would no longer be meaningful. the 'expr' part is suppose to represent the abstract purpose... The stuff required to represent an expression in gimple IL. And yes, that is currently a tree :-) Andrew
Hi, On Wed, 13 Nov 2013, Andrew MacLeod wrote: > There needs to be a place which has gimple componentry that is not > related to or require a statement. gimple.h is becoming the home for > just 0gimple statements. There are 3 (for the moment) major classes of > things that are in statements and are also used by other parts of the > compiler .. Types, Decls, and Expressions. Actually I wouldn't say gimple statements contain expressions. They refer to objects (and unfortunately also sometimes to types directly, namely in the call stmt and in the exception statements, though the latter don't exist anymore after lowering). It's those objects which have types. Currently those objects are trees and hence can be more complex than just singletons (which are the decls, constants and ssa names), that is most of the SINGLE_RHS objects. If you want to get rid of trees you somehow need to represent those objects in a different way, but they still aren't expressions in the common meaning. E.g. there won't ever be something like a gimple arithmetic addition expression (or I hope there never will be). It's always a gimple statement that assigns the addition result somewhere. Even the non-singleton objects don't exist in isolation, they're always part of some action (i.e. statement) to operate on those objects. That's why I think talking about a gimple expression as if they were somehow some stand-alone concept is fairly confusing, and introducing it now as if it would somewhen exist would lead to going down some inferior design paths. > Its true that gimple-tree would in fact be a more appropriate name at > the moment, but these gimple-* files are the core ones I'll be changing > first, so the tree part would no longer be meaningful. the 'expr' part > is suppose to represent the abstract purpose... The stuff required to > represent an expression in gimple IL. And yes, that is currently a tree > :-) Put another way: what do you envision that gimple expressions would be. For example what would you propose we could do with them? Ciao, Michael.
On Thu, Nov 14, 2013 at 10:26 AM, Michael Matz <matz@suse.de> wrote: > Put another way: what do you envision that gimple expressions would be. > For example what would you propose we could do with them? The only expressions I have in mind are memory references and aggregates, which can get pretty convoluted. Perhaps we could label them something different than expressions. They would be in the same taxonomy of "gimple values". They are operands to gimple statements, they can have multiple symbol references inside and they may have a tree like structure. Diego.
On 11/14/2013 10:26 AM, Michael Matz wrote: > Hi, > > On Wed, 13 Nov 2013, Andrew MacLeod wrote: > >> There needs to be a place which has gimple componentry that is not >> related to or require a statement. gimple.h is becoming the home for >> just 0gimple statements. There are 3 (for the moment) major classes of >> things that are in statements and are also used by other parts of the >> compiler .. Types, Decls, and Expressions. > > E.g. there won't ever be something like a gimple arithmetic addition > expression (or I hope there never will be). It's always a gimple > statement that assigns the addition result somewhere. Even the > non-singleton objects don't exist in isolation, they're always part of > some action (i.e. statement) to operate on those objects. > > That's why I think talking about a gimple expression as if they were > somehow some stand-alone concept is fairly confusing, and introducing it > now as if it would somewhen exist would lead to going down some inferior > design paths. Well, for gimple expressions I was thinking more about the addressing expressions we currently leave as trees... MEM stuff... that where most of the remaining 'expressions' are I guess, so perhaps gimple-addressing is a better term... in any case, it refers mostly to the parts of trees which are tcc_expression and are not subsumed by gimple_statement contructs. So I use expression for lack of a better term since I don't know what exact uses there are yet. Andrew
On Thu, Nov 14, 2013 at 10:34 AM, Andrew MacLeod <amacleod@redhat.com> wrote: > On 11/14/2013 10:26 AM, Michael Matz wrote: >> >> Hi, >> >> On Wed, 13 Nov 2013, Andrew MacLeod wrote: >> >>> There needs to be a place which has gimple componentry that is not >>> related to or require a statement. gimple.h is becoming the home for >>> just 0gimple statements. There are 3 (for the moment) major classes of >>> things that are in statements and are also used by other parts of the >>> compiler .. Types, Decls, and Expressions. >> >> >> E.g. there won't ever be something like a gimple arithmetic addition >> expression (or I hope there never will be). It's always a gimple >> statement that assigns the addition result somewhere. Even the >> non-singleton objects don't exist in isolation, they're always part of >> some action (i.e. statement) to operate on those objects. >> >> That's why I think talking about a gimple expression as if they were >> somehow some stand-alone concept is fairly confusing, and introducing it >> now as if it would somewhen exist would lead to going down some inferior >> design paths. > > Well, for gimple expressions I was thinking more about the addressing > expressions we currently leave as trees... MEM stuff... that where most of > the remaining 'expressions' are I guess, so perhaps gimple-addressing is a > better term... > > in any case, it refers mostly to the parts of trees which are tcc_expression > and are not subsumed by gimple_statement contructs. So I use expression for > lack of a better term since I don't know what exact uses there are yet. I think we'll end up with a hierarchy that will have some generic "value" at its base, with constants, symbols, aggregates, arrays, memrefs, etc as children. But perhaps we can wait until we have a better idea of how we want it to look like. Diego.
On 11/14/2013 10:37 AM, Diego Novillo wrote: > On Thu, Nov 14, 2013 at 10:34 AM, Andrew MacLeod <amacleod@redhat.com> wrote: >> On 11/14/2013 10:26 AM, Michael Matz wrote: >>> Hi, >>> >>> On Wed, 13 Nov 2013, Andrew MacLeod wrote: >>> >>>> There needs to be a place which has gimple componentry that is not >>>> related to or require a statement. gimple.h is becoming the home for >>>> just 0gimple statements. There are 3 (for the moment) major classes of >>>> things that are in statements and are also used by other parts of the >>>> compiler .. Types, Decls, and Expressions. >>> >>> E.g. there won't ever be something like a gimple arithmetic addition >>> expression (or I hope there never will be). It's always a gimple >>> statement that assigns the addition result somewhere. Even the >>> non-singleton objects don't exist in isolation, they're always part of >>> some action (i.e. statement) to operate on those objects. >>> >>> That's why I think talking about a gimple expression as if they were >>> somehow some stand-alone concept is fairly confusing, and introducing it >>> now as if it would somewhen exist would lead to going down some inferior >>> design paths. >> Well, for gimple expressions I was thinking more about the addressing >> expressions we currently leave as trees... MEM stuff... that where most of >> the remaining 'expressions' are I guess, so perhaps gimple-addressing is a >> better term... >> >> in any case, it refers mostly to the parts of trees which are tcc_expression >> and are not subsumed by gimple_statement contructs. So I use expression for >> lack of a better term since I don't know what exact uses there are yet. > I think we'll end up with a hierarchy that will have some generic > "value" at its base, with constants, symbols, aggregates, arrays, > memrefs, etc as children. But perhaps we can wait until we have a > better idea of how we want it to look like. > > That is pretty much what my prototypes at th cauldron had... I just hadn't fit expressions into it yet... so just left the term. but that why it is lumped in with decls and types... things that will have their tree replaced. In any case... thats all to come... Andrew
Hi, On Thu, 14 Nov 2013, Andrew MacLeod wrote: > > That's why I think talking about a gimple expression as if they were > > somehow some stand-alone concept is fairly confusing, and introducing it > > now as if it would somewhen exist would lead to going down some inferior > > design paths. > > Well, for gimple expressions I was thinking more about the addressing > expressions we currently leave as trees... MEM stuff... that where most > of the remaining 'expressions' are I guess, so perhaps gimple-addressing > is a better term... > > in any case, it refers mostly to the parts of trees which are > tcc_expression and are not subsumed by gimple_statement contructs. So I > use expression for lack of a better term since I don't know what exact > uses there are yet. Well, I can precisely name you the set of things you mean then, and I wouldn't call any of them expressions (all of them either represent a (sub)object or a statement of fact, not a computation (except as part of how to get at the specified object)): CODE_CLASS == tcc_reference : COMPONENT_REF, BIT_FIELD_REF, ARRAY_REF, ARRAY_RANGE_REF, REALPART_EXPR, IMAGPART_EXPR, VIEW_CONVERT_EXPR, INDIRECT_REF, TARGET_MEM_REF, MEM_REF CODE == : CONSTRUCTOR, OBJ_TYPE_REF, ASSERT_EXPR, ADDR_EXPR, WITH_SIZE_EXPR The rest is the trivial SSA_NAME, tcc_constant and tcc_declaration, what I called singletons. Most of the codes above have a shallow one- or two-level structure in what they operate on, or can be made so by some more lowering. A few of them can contain arbitrarily deep recursive structures (but not of all possible trees), and I think that's the only thing that would remain if the above would be better melded into serveral new statement types. That's of course also the difficult part to get sensibly rid of, because the recursive structure lends itself to something that terribly looks like 'tree'. I think if following through with the whole plan there would (and should) be nothing remaining that could be called a gimple expression. Ciao, Michael.
On 11/14/2013 10:57 AM, Michael Matz wrote: > Hi, > > On Thu, 14 Nov 2013, Andrew MacLeod wrote: > >>> That's why I think talking about a gimple expression as if they were >>> somehow some stand-alone concept is fairly confusing, and introducing it >>> now as if it would somewhen exist would lead to going down some inferior >>> design paths. >> Well, for gimple expressions I was thinking more about the addressing >> expressions we currently leave as trees... MEM stuff... that where most >> of the remaining 'expressions' are I guess, so perhaps gimple-addressing >> is a better term... >> >> in any case, it refers mostly to the parts of trees which are >> tcc_expression and are not subsumed by gimple_statement contructs. So I >> use expression for lack of a better term since I don't know what exact >> uses there are yet. > Well, I can precisely name you the set of things you mean then, and I > wouldn't call any of them expressions (all of them either represent a > (sub)object or a statement of fact, not a computation (except as part of > how to get at the specified object)): > > CODE_CLASS == tcc_reference > : COMPONENT_REF, BIT_FIELD_REF, ARRAY_REF, ARRAY_RANGE_REF, > REALPART_EXPR, IMAGPART_EXPR, VIEW_CONVERT_EXPR, INDIRECT_REF, > TARGET_MEM_REF, MEM_REF > CODE == > : CONSTRUCTOR, OBJ_TYPE_REF, ASSERT_EXPR, ADDR_EXPR, WITH_SIZE_EXPR > > The rest is the trivial SSA_NAME, tcc_constant and tcc_declaration, what I > called singletons. > > Most of the codes above have a shallow one- or two-level structure in what > they operate on, or can be made so by some more lowering. A few of them > can contain arbitrarily deep recursive structures (but not of all possible > trees), and I think that's the only thing that would remain if the above > would be better melded into serveral new statement types. That's of > course also the difficult part to get sensibly rid of, because the > recursive structure lends itself to something that terribly looks like > 'tree'. > > I think if following through with the whole plan there would (and should) > be nothing remaining that could be called a gimple expression. > > very possibly, i just haven't gotten to those parts yet. I can change the name back to gimple-decl.[ch] or some such thing if you like that better. Andrew
Hi, On Thu, 14 Nov 2013, Andrew MacLeod wrote: > > I think if following through with the whole plan there would (and > > should) be nothing remaining that could be called a gimple expression. > > very possibly, i just haven't gotten to those parts yet. I can change > the name back to gimple-decl.[ch] or some such thing if you like that > better. -object? -operand? -stuff? ;-) Will all of these splits land at trunk, i.e. 4.9? Why the hurry when not even such high-level things are clear? I mean how can you think about rearchitecting the gimple data structures without having looked at the current details. It's clear that not every detail of the design can be fixated at this point, but basic questions like "what's the operands?", "will there be expressions?", "how do we iterate?", "recursive structures or not?" should at least get some answer before really starting grind work, shouldn't they? Ciao, Michael.
On Thu, Nov 14, 2013 at 11:13 AM, Andrew MacLeod <amacleod@redhat.com> wrote: > very possibly, i just haven't gotten to those parts yet. I can change the > name back to gimple-decl.[ch] or some such thing if you like that better. As much as I hate to paint name sheds: gimple-val.[ch]. Diego.
On 11/14/2013 11:23 AM, Michael Matz wrote: > Hi, > > On Thu, 14 Nov 2013, Andrew MacLeod wrote: > >>> I think if following through with the whole plan there would (and >>> should) be nothing remaining that could be called a gimple expression. >> very possibly, i just haven't gotten to those parts yet. I can change >> the name back to gimple-decl.[ch] or some such thing if you like that >> better. > -object? -operand? -stuff? ;-) Will all of these splits land at trunk, > i.e. 4.9? Why the hurry when not even such high-level things are clear? > I mean how can you think about rearchitecting the gimple data structures > without having looked at the current details. It's clear that not every > detail of the design can be fixated at this point, but basic questions > like "what's the operands?", "will there be expressions?", "how do we > iterate?", "recursive structures or not?" should at least get some answer > before really starting grind work, shouldn't they? > The splits are for header file cleanup and re-structuring into logical components. As I mentioned in the original post, the file is needed to break dependency cycles between gimple.h (the statements) , the iterators, and gimplification. It is for the gimple stuff which doesn't need any of those things but is consumed by them. This really has nothing to do with my future plans, other than the fact that I also said whatever is in this file is will eventually be split into more things, but I'm not ready to do those splits yet, thus the gimple-blah name doesn't matter to me. gimple-expr seemed convenient at the time but clearly you don't like it, and I'll happily call it whatever you want. It's a grab bag of all the gimple values which are still trees... maybe the suggested gimple-val.[ch] is ok? Andrew
Diego Novillo <dnovillo@google.com> wrote: >On Thu, Nov 14, 2013 at 11:13 AM, Andrew MacLeod <amacleod@redhat.com> >wrote: > >> very possibly, i just haven't gotten to those parts yet. I can change >the >> name back to gimple-decl.[ch] or some such thing if you like that >better. > >As much as I hate to paint name sheds: gimple-val.[ch]. Yeah, everything that is a gimple value ... Richard. > >Diego.
* ada/gcc-interface/trans.c: Include gimplify.h. * c/c-typeck.c: Include gimplify.h. * c-family/c-common.c: Include gimplify.h. * c-family/c-gimplify.c: Likewise. * c-family/cilk.c: Likewise. * c-family/c-omp.c: Include gimple-expr.h instead of gimple.h. * c-family/c-ubsan.c: Don't include gimple.h. * cp/class.c: Include gimplify.h. * cp/cp-gimplify.c: Likewise. * cp/error.c: Likewise. * cp/init.c: Likewise. * cp/optimize.c: Likewise. * cp/pt.c: Likewise. * cp/semantics.c: Likewise. * cp/tree.c: Likewise. * cp/vtable-class-hierarchy.c: Likewise. * cp/decl2.c: Don't include gimple.h. * cp/except.c: Likewise. * cp/method.c: Include pointer-set.h instead of gimple.h. * fortran/f95-lang.c: Don't include gimple.h. * fortran/trans-array.c: Include gimple-expr.h instead of gimple.h. * fortran/trans.c: Likewise. * fortran/trans-decl.c: Likewise. * fortran/trans-expr.c: Include gimplify.h. * fortran/trans-openmp.c: Likewise. * go/go-lang.c: Include gimplify.h. * go/gofrontend/expressions.cc: Likewise. * go/gofrontend/gogo-tree.cc: Likewise. * go/gofrontend/types.cc: Likewise. * java/java-gimplify.c: Include gimplify.h. * objc/objc-act.c: Include gimplify.h. Index: ada/gcc-interface/trans.c =================================================================== *** ada/gcc-interface/trans.c (revision 204496) --- ada/gcc-interface/trans.c (working copy) *************** *** 33,39 **** #include "output.h" #include "libfuncs.h" /* For set_stack_check_libfunc. */ #include "tree-iterator.h" ! #include "gimple.h" #include "bitmap.h" #include "cgraph.h" #include "diagnostic.h" --- 33,39 ---- #include "output.h" #include "libfuncs.h" /* For set_stack_check_libfunc. */ #include "tree-iterator.h" ! #include "gimplify.h" #include "bitmap.h" #include "cgraph.h" #include "diagnostic.h" Index: c/c-typeck.c =================================================================== *** c/c-typeck.c (revision 204496) --- c/c-typeck.c (working copy) *************** along with GCC; see the file COPYING3. *** 36,42 **** #include "target.h" #include "tree-iterator.h" #include "bitmap.h" ! #include "gimple.h" #include "tree-inline.h" #include "omp-low.h" #include "c-family/c-objc.h" --- 36,42 ---- #include "target.h" #include "tree-iterator.h" #include "bitmap.h" ! #include "gimplify.h" #include "tree-inline.h" #include "omp-low.h" #include "c-family/c-objc.h" Index: c-family/c-common.c =================================================================== *** c-family/c-common.c (revision 204496) --- c-family/c-common.c (working copy) *************** along with GCC; see the file COPYING3. *** 42,47 **** --- 42,48 ---- #include "opts.h" #include "cgraph.h" #include "target-def.h" + #include "gimplify.h" cpp_reader *parse_in; /* Declared in c-pragma.h. */ Index: c-family/c-gimplify.c =================================================================== *** c-family/c-gimplify.c (revision 204496) --- c-family/c-gimplify.c (working copy) *************** along with GCC; see the file COPYING3. *** 29,35 **** #include "tm.h" #include "tree.h" #include "c-common.h" ! #include "gimple.h" #include "tree-inline.h" #include "diagnostic-core.h" #include "langhooks.h" --- 29,35 ---- #include "tm.h" #include "tree.h" #include "c-common.h" ! #include "gimplify.h" #include "tree-inline.h" #include "diagnostic-core.h" #include "langhooks.h" Index: c-family/cilk.c =================================================================== *** c-family/cilk.c (revision 204496) --- c-family/cilk.c (working copy) *************** along with GCC; see the file COPYING3. *** 25,31 **** #include "coretypes.h" #include "tree.h" #include "langhooks.h" ! #include "gimple.h" #include "tree-iterator.h" #include "tree-inline.h" #include "c-family/c-common.h" --- 25,31 ---- #include "coretypes.h" #include "tree.h" #include "langhooks.h" ! #include "gimplify.h" #include "tree-iterator.h" #include "tree-inline.h" #include "c-family/c-common.h" Index: c-family/c-omp.c =================================================================== *** c-family/c-omp.c (revision 204496) --- c-family/c-omp.c (working copy) *************** along with GCC; see the file COPYING3. *** 27,33 **** #include "tree.h" #include "c-common.h" #include "c-pragma.h" ! #include "gimple.h" /* For create_tmp_var_raw. */ #include "langhooks.h" --- 27,33 ---- #include "tree.h" #include "c-common.h" #include "c-pragma.h" ! #include "gimple-expr.h" #include "langhooks.h" Index: c-family/c-ubsan.c =================================================================== *** c-family/c-ubsan.c (revision 204496) --- c-family/c-ubsan.c (working copy) *************** along with GCC; see the file COPYING3. *** 24,30 **** #include "tree.h" #include "alloc-pool.h" #include "cgraph.h" - #include "gimple.h" #include "output.h" #include "toplev.h" #include "ubsan.h" --- 24,29 ---- Index: cp/class.c =================================================================== *** cp/class.c (revision 204496) --- cp/class.c (working copy) *************** along with GCC; see the file COPYING3. *** 36,41 **** --- 36,42 ---- #include "splay-tree.h" #include "pointer-set.h" #include "hash-table.h" + #include "gimplify.h" /* The number of nested classes being processed. If we are not in the scope of any class, this is zero. */ Index: cp/cp-gimplify.c =================================================================== *** cp/cp-gimplify.c (revision 204496) --- cp/cp-gimplify.c (working copy) *************** along with GCC; see the file COPYING3. *** 27,33 **** #include "cp-tree.h" #include "c-family/c-common.h" #include "tree-iterator.h" ! #include "gimple.h" #include "hashtab.h" #include "pointer-set.h" #include "flags.h" --- 27,33 ---- #include "cp-tree.h" #include "c-family/c-common.h" #include "tree-iterator.h" ! #include "gimplify.h" #include "hashtab.h" #include "pointer-set.h" #include "flags.h" Index: cp/error.c =================================================================== *** cp/error.c (revision 204496) --- cp/error.c (working copy) *************** along with GCC; see the file COPYING3. *** 33,38 **** --- 33,39 ---- #include "pointer-set.h" #include "c-family/c-objc.h" #include "ubsan.h" + #include "gimplify.h" #include <new> // For placement-new. Index: cp/init.c =================================================================== *** cp/init.c (revision 204496) --- cp/init.c (working copy) *************** along with GCC; see the file COPYING3. *** 28,33 **** --- 28,34 ---- #include "cp-tree.h" #include "flags.h" #include "target.h" + #include "gimplify.h" static bool begin_init_stmts (tree *, tree *); static tree finish_init_stmts (bool, tree, tree); Index: cp/optimize.c =================================================================== *** cp/optimize.c (revision 204496) --- cp/optimize.c (working copy) *************** along with GCC; see the file COPYING3. *** 34,40 **** #include "langhooks.h" #include "diagnostic-core.h" #include "dumpfile.h" ! #include "gimple.h" #include "tree-iterator.h" #include "cgraph.h" --- 34,40 ---- #include "langhooks.h" #include "diagnostic-core.h" #include "dumpfile.h" ! #include "gimplify.h" #include "tree-iterator.h" #include "cgraph.h" Index: cp/pt.c =================================================================== *** cp/pt.c (revision 204496) --- cp/pt.c (working copy) *************** along with GCC; see the file COPYING3. *** 42,47 **** --- 42,48 ---- #include "timevar.h" #include "tree-iterator.h" #include "type-utils.h" + #include "gimplify.h" /* The type of functions taking a tree, and some additional data, and returning an int. */ Index: cp/semantics.c =================================================================== *** cp/semantics.c (revision 204496) --- cp/semantics.c (working copy) *************** along with GCC; see the file COPYING3. *** 41,47 **** #include "tree-iterator.h" #include "vec.h" #include "target.h" ! #include "gimple.h" #include "bitmap.h" #include "hash-table.h" #include "omp-low.h" --- 41,47 ---- #include "tree-iterator.h" #include "vec.h" #include "target.h" ! #include "gimplify.h" #include "bitmap.h" #include "hash-table.h" #include "omp-low.h" Index: cp/tree.c =================================================================== *** cp/tree.c (revision 204496) --- cp/tree.c (working copy) *************** along with GCC; see the file COPYING3. *** 30,36 **** #include "convert.h" #include "cgraph.h" #include "splay-tree.h" ! #include "gimple.h" /* gimple_has_body_p */ #include "hash-table.h" static tree bot_manip (tree *, int *, void *); --- 30,36 ---- #include "convert.h" #include "cgraph.h" #include "splay-tree.h" ! #include "gimplify.h" #include "hash-table.h" static tree bot_manip (tree *, int *, void *); Index: cp/vtable-class-hierarchy.c =================================================================== *** cp/vtable-class-hierarchy.c (revision 204496) --- cp/vtable-class-hierarchy.c (working copy) *************** along with GCC; see the file COPYING3. *** 118,124 **** #include "cgraph.h" #include "tree-iterator.h" #include "vtable-verify.h" ! #include "gimple.h" static int num_calls_to_regset = 0; static int num_calls_to_regpair = 0; --- 118,124 ---- #include "cgraph.h" #include "tree-iterator.h" #include "vtable-verify.h" ! #include "gimplify.h" static int num_calls_to_regset = 0; static int num_calls_to_regpair = 0; Index: cp/decl2.c =================================================================== *** cp/decl2.c (revision 204496) --- cp/decl2.c (working copy) *************** along with GCC; see the file COPYING3. *** 45,51 **** #include "c-family/c-pragma.h" #include "dumpfile.h" #include "intl.h" - #include "gimple.h" #include "pointer-set.h" #include "splay-tree.h" #include "langhooks.h" --- 45,50 ---- Index: cp/except.c =================================================================== *** cp/except.c (revision 204496) --- cp/except.c (working copy) *************** along with GCC; see the file COPYING3. *** 31,37 **** #include "tree-inline.h" #include "tree-iterator.h" #include "target.h" - #include "gimple.h" static void push_eh_cleanup (tree); static tree prepare_eh_type (tree); --- 31,36 ---- Index: cp/method.c =================================================================== *** cp/method.c (revision 204496) --- cp/method.c (working copy) *************** along with GCC; see the file COPYING3. *** 34,40 **** #include "common/common-target.h" #include "diagnostic.h" #include "cgraph.h" ! #include "gimple.h" /* Various flags to control the mangling process. */ --- 34,40 ---- #include "common/common-target.h" #include "diagnostic.h" #include "cgraph.h" ! #include "pointer-set.h" /* Various flags to control the mangling process. */ Index: fortran/f95-lang.c =================================================================== *** fortran/f95-lang.c (revision 204496) --- fortran/f95-lang.c (working copy) *************** along with GCC; see the file COPYING3. *** 28,34 **** #include "system.h" #include "coretypes.h" #include "tree.h" - #include "gimple.h" #include "flags.h" #include "langhooks.h" #include "langhooks-def.h" --- 28,33 ---- Index: fortran/trans-array.c =================================================================== *** fortran/trans-array.c (revision 204496) --- fortran/trans-array.c (working copy) *************** along with GCC; see the file COPYING3. *** 79,85 **** #include "system.h" #include "coretypes.h" #include "tree.h" ! #include "gimple.h" /* For create_tmp_var_name. */ #include "diagnostic-core.h" /* For internal_error/fatal_error. */ #include "flags.h" #include "gfortran.h" --- 79,85 ---- #include "system.h" #include "coretypes.h" #include "tree.h" ! #include "gimple-expr.h" #include "diagnostic-core.h" /* For internal_error/fatal_error. */ #include "flags.h" #include "gfortran.h" Index: fortran/trans.c =================================================================== *** fortran/trans.c (revision 204496) --- fortran/trans.c (working copy) *************** along with GCC; see the file COPYING3. *** 22,28 **** #include "system.h" #include "coretypes.h" #include "tree.h" ! #include "gimple.h" /* For create_tmp_var_raw. */ #include "tree-iterator.h" #include "diagnostic-core.h" /* For internal_error. */ #include "flags.h" --- 22,28 ---- #include "system.h" #include "coretypes.h" #include "tree.h" ! #include "gimple-expr.h" /* For create_tmp_var_raw. */ #include "tree-iterator.h" #include "diagnostic-core.h" /* For internal_error. */ #include "flags.h" Index: fortran/trans-decl.c =================================================================== *** fortran/trans-decl.c (revision 204496) --- fortran/trans-decl.c (working copy) *************** along with GCC; see the file COPYING3. *** 26,32 **** #include "tm.h" #include "tree.h" #include "tree-dump.h" ! #include "gimple.h" /* For create_tmp_var_raw. */ #include "ggc.h" #include "diagnostic-core.h" /* For internal_error. */ #include "toplev.h" /* For announce_function. */ --- 26,32 ---- #include "tm.h" #include "tree.h" #include "tree-dump.h" ! #include "gimple-expr.h" /* For create_tmp_var_raw. */ #include "ggc.h" #include "diagnostic-core.h" /* For internal_error. */ #include "toplev.h" /* For announce_function. */ Index: fortran/trans-expr.c =================================================================== *** fortran/trans-expr.c (revision 204496) --- fortran/trans-expr.c (working copy) *************** along with GCC; see the file COPYING3. *** 38,43 **** --- 38,44 ---- /* Only for gfc_trans_assign and gfc_trans_pointer_assign. */ #include "trans-stmt.h" #include "dependency.h" + #include "gimplify.h" /* Convert a scalar to an array descriptor. To be used for assumed-rank Index: fortran/trans-openmp.c =================================================================== *** fortran/trans-openmp.c (revision 204496) --- fortran/trans-openmp.c (working copy) *************** along with GCC; see the file COPYING3. *** 23,29 **** #include "system.h" #include "coretypes.h" #include "tree.h" ! #include "gimple.h" /* For create_tmp_var_raw. */ #include "diagnostic-core.h" /* For internal_error. */ #include "gfortran.h" #include "trans.h" --- 23,29 ---- #include "system.h" #include "coretypes.h" #include "tree.h" ! #include "gimplify.h" /* For create_tmp_var_raw. */ #include "diagnostic-core.h" /* For internal_error. */ #include "gfortran.h" #include "trans.h" Index: go/go-lang.c =================================================================== *** go/go-lang.c (revision 204496) --- go/go-lang.c (working copy) *************** along with GCC; see the file COPYING3. *** 23,29 **** #include "coretypes.h" #include "opts.h" #include "tree.h" ! #include "gimple.h" #include "ggc.h" #include "toplev.h" #include "debug.h" --- 23,29 ---- #include "coretypes.h" #include "opts.h" #include "tree.h" ! #include "gimplify.h" #include "ggc.h" #include "toplev.h" #include "debug.h" Index: go/gofrontend/expressions.cc =================================================================== *** go/gofrontend/expressions.cc (revision 204496) --- go/gofrontend/expressions.cc (working copy) *************** *** 12,17 **** --- 12,18 ---- #include "intl.h" #include "tree.h" #include "gimple.h" + #include "gimplify.h" #include "tree-iterator.h" #include "convert.h" #include "real.h" Index: go/gofrontend/gogo-tree.cc =================================================================== *** go/gofrontend/gogo-tree.cc (revision 204496) --- go/gofrontend/gogo-tree.cc (working copy) *************** *** 9,14 **** --- 9,15 ---- #include "toplev.h" #include "tree.h" #include "gimple.h" + #include "gimplify.h" #include "tree-iterator.h" #include "cgraph.h" #include "langhooks.h" Index: go/gofrontend/types.cc =================================================================== *** go/gofrontend/types.cc (revision 204496) --- go/gofrontend/types.cc (working copy) *************** *** 10,15 **** --- 10,16 ---- #include "intl.h" #include "tree.h" #include "gimple.h" + #include "gimplify.h" #include "real.h" #include "convert.h" Index: java/java-gimplify.c =================================================================== *** java/java-gimplify.c (revision 204496) --- java/java-gimplify.c (working copy) *************** The Free Software Foundation is independ *** 27,33 **** #include "tree.h" #include "java-tree.h" #include "dumpfile.h" ! #include "gimple.h" static tree java_gimplify_block (tree); static enum gimplify_status java_gimplify_modify_expr (tree *); --- 27,33 ---- #include "tree.h" #include "java-tree.h" #include "dumpfile.h" ! #include "gimplify.h" static tree java_gimplify_block (tree); static enum gimplify_status java_gimplify_modify_expr (tree *); Index: objc/objc-act.c =================================================================== *** objc/objc-act.c (revision 204496) --- objc/objc-act.c (working copy) *************** along with GCC; see the file COPYING3. *** 60,66 **** #include "tree-pretty-print.h" /* For enum gimplify_status */ ! #include "gimple.h" /* For encode_method_prototype(). */ #include "objc-encoding.h" --- 60,66 ---- #include "tree-pretty-print.h" /* For enum gimplify_status */ ! #include "gimplify.h" /* For encode_method_prototype(). */ #include "objc-encoding.h"