On Thu, Nov 14, 2013 at 9:49 PM, Andrew MacLeod <amacl...@redhat.com> wrote:
> On 11/14/2013 05:16 PM, Joseph S. Myers wrote:
>>
>> On Thu, 14 Nov 2013, Diego Novillo wrote:
>>
>>> This patch contains the mechanical side-effects from
>>> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01663.html
>>
>> There are rather a lot of "Include tm.h" changes here - especially in
>> front ends, where we've tried to eliminate tm.h calls, and put comments on
>> some of those remaining saying exactly what target macros are used to make
>> clear what's needed to eliminate them. Putting in these includes, without
>> clear comments explaining how to eliminate them, seems a step backwards.
>
> The problem is larger than that... function.h includes tm.h as well... and
> something like 140ish files include function.h, not to mention another 5
> include files bring it in... basic-block.h, cfgloop.h, cgraph.h, expr.h,
> and gimple-streamer.h
Yeah. For now, I'm going to leave the builtins.h declarations in
tree.h. This is a similar problem that I had with expr.h. There are
parts of it that FEs want, but others they don't.
> I' ve been thinking that the only way to really tackle this is to flatten
> *everything* so that nothing but .c files have #includes, and then trim out
> all the includes that each .c requires, and then see where we sit. .h files
> bringing in other .h files really muck things up.
Right. Perhaps starting with Joseph's suggestion of having
tree-{builtins,expr}.h is a good start.
Diego.
