Message ID | CAMe9rOqm8oxgMEtBDnfmZcn5OF7gNE+cdc9mqO1+WNs1dexTGg@mail.gmail.com |
---|---|
State | New |
Headers | show |
On 11/14/2013 05:06 PM, H.J. Lu wrote: > On Thu, Nov 14, 2013 at 8:34 AM, Andrew MacLeod <amacleod@redhat.com> wrote: >> 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 > It breaks Ada build. I checked in the following patch to unbreak > it. > > Thanks. I was bootstrapping Ada as well until the end of last week. It seems to be broken right now, so I had turned Ada off until the issue is resolved. Andrew
On 11/14/13 16:00, Andrew MacLeod wrote: > > I was bootstrapping Ada as well until the end of last week. It seems > to be broken right now, so I had turned Ada off until the issue is > resolved. Ada should be working again... At least on x86_64. I'm still looking at it on Itanic, but I suspect you aren't building Ada on that :-) jeff
On 11/14/2013 06:56 PM, Jeff Law wrote: > On 11/14/13 16:00, Andrew MacLeod wrote: > >> >> I was bootstrapping Ada as well until the end of last week. It seems >> to be broken right now, so I had turned Ada off until the issue is >> resolved. > Ada should be working again... At least on x86_64. I'm still looking > at it on Itanic, but I suspect you aren't building Ada on that :-) > > jeff I'll check again. it was still busted earlier this afternoon Andrew
> I was bootstrapping Ada as well until the end of last week. It seems > to be broken right now, so I had turned Ada off until the issue is resolved. Well, it's equivalent to knowingly breaking it further when you're making systemic changes like these... A quick search with bugzilla would have given the revision that broke it and you could have reverted it locally instead.
Index: ada/ChangeLog =================================================================== --- ada/ChangeLog (revision 204825) +++ ada/ChangeLog (working copy) @@ -1,3 +1,7 @@ +2013-11-14 H.J. Lu <hongjiu.lu@intel.com> + + * gcc-interface/trans.c: Include gimple.h and pointer-set.h. + 2013-11-12 Andrew MacLeod <amacleod@redhat.com> * gcc-interface/trans.c: Include gimplify.h. Index: ada/gcc-interface/trans.c =================================================================== --- ada/gcc-interface/trans.c (revision 204825) +++ ada/gcc-interface/trans.c (working copy) @@ -33,7 +33,9 @@ #include "output.h" #include "libfuncs.h" /* For set_stack_check_libfunc. */ #include "tree-iterator.h" +#include "gimple.h" #include "gimplify.h" +#include "pointer-set.h" #include "bitmap.h" #include "cgraph.h" #include "diagnostic.h"