diff mbox

[3/4] Separate gimple.[ch] and gimplify.[ch] - front end files

Message ID CAMe9rOqm8oxgMEtBDnfmZcn5OF7gNE+cdc9mqO1+WNs1dexTGg@mail.gmail.com
State New
Headers show

Commit Message

H.J. Lu Nov. 14, 2013, 10:06 p.m. UTC
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.

Comments

Andrew MacLeod Nov. 14, 2013, 11 p.m. UTC | #1
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
Jeff Law Nov. 14, 2013, 11:56 p.m. UTC | #2
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
Andrew MacLeod Nov. 15, 2013, 12:14 a.m. UTC | #3
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
Eric Botcazou Nov. 15, 2013, 8:09 a.m. UTC | #4
>   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.
diff mbox

Patch

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"