Re: Factor unrelated declarations out of tree.h (2/2)

[Andrew MacLeod <amacleod at redhat dot com>]

On 11/15/2013 05:01 AM, Richard Biener wrote:
> On Fri, Nov 15, 2013 at 3:49 AM, Andrew MacLeod <amacleod@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
> >
> > so pretty much every file in existence gets tm.h one way or another :-P
> > Aren't our includes spectacular?
> >
> > 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.
> Yeah, though this has interesting effects on includes that do stuff like
>
> #ifdef NO_DOLLARS_IN_LABELS
> ...
>
> where the presence of this definition depends on another header file
> and thus the ultimate outcome in your .c file depends on include file
> order.So ... no #ifdefs inside headers?  Or have meta-defines like
no ifdefs sounds harsh... I wonder how frequently this is an issue...    
If they tend to be caused mostly by things like tm.h or certain other 
files, you could hard-force the required .h file that would normally 
define the macro, like:
#ifndef GCC_TM_H
error (" Must include tm_h before this file:");
#endif

without actually including it... but that may not always be possible 
either since you have to know where it comes from and update everywhere 
if you ever change it.  Although I suppose that's already true if you 
depend on it.

These situations are pretty shaky to start with and should probably all 
be identified and resolved in some form.  Any idea how to autodetect 
these situations that actually matter? other than manual inspection?  
I'm sure people know of a few , but getting them all could be interesting.

Look for uses of macros in a header file which aren't defined in the 
header maybe, and inspect those...?

> #define NO_DOLLARS_IN_LABELS_DEFINED
>
> and
>
> #ifndef NO_DOLLARS_IN_LABELS_DEFINED
> #error ...
> #endif
>
> at use sites?

If there arent a lot of them, this kind of granularity would be OK... it 
might get kinda messy if there are a hundred of them tho.

Im not sure, a lot depends on how many and where they come from I guess.

Andrew