This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


-- 
H.J.
---
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"


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]