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

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.

I was contemplating giving that a go over the weekend or maybe next week 
to see what it looks like... I have some scripts that flatten includes 
into the .c files and then try to trim out the ones which aren't needed 
from each .c file.

Andrew

btw, I ran tm.h through the include removal script for the c family 
front end files... The attached patch compiles on x64 and removes 37 
includes from the front end files.... those are just the extraneous 
ones...   but it may be helpful...

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

#define NO_DOLLARS_IN_LABELS_DEFINED

and

#ifndef NO_DOLLARS_IN_LABELS_DEFINED
#error ...
#endif

at use sites?

Richard.

> I was contemplating giving that a go over the weekend or maybe next week to
> see what it looks like... I have some scripts that flatten includes into the
> .c files and then try to trim out the ones which aren't needed from each .c
> file.
>
> Andrew
>
> btw, I ran tm.h through the include removal script for the c family front
> end files... The attached patch compiles on x64 and removes 37 includes from
> the front end files.... those are just the extraneous ones...   but it may
> be helpful...

On Thu, Nov 14, 2013 at 9:49 PM, 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

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.

On Thu, 14 Nov 2013, Andrew MacLeod 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

Front end and GIMPLE optimizer files should avoid including all of those 
where possible - and if needed, the bits requiring tm.h should be 
separated from the bits not requiring it.

> btw, I ran tm.h through the include removal script for the c family front end
> files... The attached patch compiles on x64 and removes 37 includes from the
> front end files.... those are just the extraneous ones...   but it may be
> helpful...

When trimming tm.h includes you need to be careful about either the .c 
file itself, or headers it includes, referencing target macros in ways 
that don't cause build failures when they are missing (that is, 
#ifdef etc., rather than if ()).  And, I don't think it's helpful to 
remove tm.h includes from a file just because some other header implicitly 
includes it.  For example, in your patch. cp/class.c uses BITS_PER_UNIT, 
MAX_FIXED_MODE_SIZE, PCC_BITFIELD_TYPE_MATTERS, STRUCTURE_SIZE_BOUNDARY, 
TARGET_VTABLE_DATA_ENTRY_DISTANCE, TARGET_VTABLE_ENTRY_ALIGN and 
TARGET_VTABLE_USES_DESCRIPTORS; removing the tm.h include makes things 
look cleaner than they are.

(Actually, the C++ front end can't really be usefully cleaned up regarding 
tm.h yet because cp-tree.h uses NO_DOLLAR_IN_LABEL and NO_DOT_IN_LABEL in 
#if conditionals.)

Regarding the case of headers depending on tm.h in a nonobvious way (#if 
rather than anything that will clearly fail if tm.h isn't included): my 
inclination would be to put #error directives in such files so they fail 
immediately if tm.h hasn't been included first (TM_H isn't defined).

The following headers appear to use target macros (there might be some 
false positives in this list).  This does *not* mean such #error should be 
added to all of them; it should be added only after investigation of 
whether it's actually needed to ensure an obvious failure, and only if it 
doesn't mean adding lots of tm.h includes to files without them.  In the 
case of tree.h, for example, the BITS_PER_UNIT uses will cause obvious 
failures if any of the affected macros are used without tm.h, while the 
other three target macros uses - NO_DOLLAR_IN_LABEL NO_DOT_IN_LABEL 
TARGET_DLLIMPORT_DECL_ATTRIBUTES - only affect a few users and so the 
relevant bits should probably be split out of tree.h.

ada/gcc-interface/gigi.h
ada/gcc-interface/lang-specs.h
addresses.h
bb-reorder.h
builtins.h
cfgloop.h
collect2-aix.h
conditions.h
cp/cp-tree.h
cp/lang-specs.h
dbxout.h
dwarf2out.h
expmed.h
flags.h
fortran/gfortran.h
function.h
gcse.h
hard-reg-set.h
hosthooks-def.h
ira-int.h
ira.h
libfuncs.h
lower-subreg.h
lra-int.h
machmode.h
objcp/lang-specs.h
optabs.h
output.h
real.h
regrename.h
regs.h
reload.h
rtl.h
target-def.h
target-globals.h
target.h
tree-dfa.h
tree.h

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

On 11/15/2013 08:16 AM, Joseph S. Myers wrote:
> On Thu, 14 Nov 2013, Andrew MacLeod wrote:
>
>
>> btw, I ran tm.h through the include removal script for the c family front end
>> files... The attached patch compiles on x64 and removes 37 includes from the
>> front end files.... those are just the extraneous ones...   but it may be
>> helpful...
> When trimming tm.h includes you need to be careful about either the .c
> file itself, or headers it includes, referencing target macros in ways
> that don't cause build failures when they are missing (that is,
> #ifdef etc., rather than if ()).  And, I don't think it's helpful to
> remove tm.h includes from a file just because some other header implicitly
> includes it.  For example, in your patch. cp/class.c uses BITS_PER_UNIT,
> MAX_FIXED_MODE_SIZE, PCC_BITFIELD_TYPE_MATTERS, STRUCTURE_SIZE_BOUNDARY,
> TARGET_VTABLE_DATA_ENTRY_DISTANCE, TARGET_VTABLE_ENTRY_ALIGN and
> TARGET_VTABLE_USES_DESCRIPTORS; removing the tm.h include makes things
> look cleaner than they are.
Which is why I made the earlier point about flattening everything before 
it really means much in analysis terms... The patch was just meant to 
show that we can strip a lot of things out. .. when those other files 
are flattened, yeah, it may end up back.
>
> (Actually, the C++ front end can't really be usefully cleaned up regarding
> tm.h yet because cp-tree.h uses NO_DOLLAR_IN_LABEL and NO_DOT_IN_LABEL in
> #if conditionals.)
>
> Regarding the case of headers depending on tm.h in a nonobvious way (#if
> rather than anything that will clearly fail if tm.h isn't included): my
> inclination would be to put #error directives in such files so they fail
> immediately if tm.h hasn't been included first (TM_H isn't defined).
Ah yes, I just suggested this as a way to handle it as well in a 
different note.... certainly they all require manual inspection, and 
identifying all cases could be interesting, but is something we could 
start at least with the ones we know.

Andrew

On Fri, 15 Nov 2013, Richard Biener wrote:

> 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
> 
> #define NO_DOLLARS_IN_LABELS_DEFINED
> 
> and
> 
> #ifndef NO_DOLLARS_IN_LABELS_DEFINED
> #error ...
> #endif
> 
> at use sites?

Rather than such a meta-define, I prefer changing the semantics of the 
macro itself from defined/undefined to nonzero/zero, changing the users 
from #if to if () conditionals (or ? :, as appropriate), and adding a 
default zero definition to defaults.h along with updating all definitions, 
users and documentation.  A meta-define seems just as error-prone as the 
original #ifdef.

Similarly, for any macros with default definitions scattered around the 
source tree rather than in defaults.h, moving them to defaults.h is a good 
idea.

Probably I should adapt my target-macro-listing scripts to list target 
macros used in #if/#ifdef/#ifndef/#elif, outside of defaults.h, so we can 
see how big this part of the problem is.

On 11/15/2013 08:31 AM, Joseph S. Myers wrote:
> On Fri, 15 Nov 2013, Richard Biener wrote:
>
>> 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
>>
>> #define NO_DOLLARS_IN_LABELS_DEFINED
>>
>> and
>>
>> #ifndef NO_DOLLARS_IN_LABELS_DEFINED
>> #error ...
>> #endif
>>
>> at use sites?
> Rather than such a meta-define, I prefer changing the semantics of the
> macro itself from defined/undefined to nonzero/zero, changing the users
> from #if to if () conditionals (or ? :, as appropriate), and adding a
> default zero definition to defaults.h along with updating all definitions,
> users and documentation.  A meta-define seems just as error-prone as the
> original #ifdef.
I like this a lot actually.... then you can tell whether its been 
defined or not... Although I suppose it depends on when and where the 
non-default value comes from, and that it is properly included in the .c 
file and not missed.  It ought to cover the vast majority of cases anyway.
>
> Similarly, for any macros with default definitions scattered around the
> source tree rather than in defaults.h, moving them to defaults.h is a good
> idea.
I think this is also a good idea.

Andrew

On Fri, Nov 15, 2013 at 2:39 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> On 11/15/2013 08:31 AM, Joseph S. Myers wrote:
>>
>> On Fri, 15 Nov 2013, Richard Biener wrote:
>>
>>> 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
>>>
>>> #define NO_DOLLARS_IN_LABELS_DEFINED
>>>
>>> and
>>>
>>> #ifndef NO_DOLLARS_IN_LABELS_DEFINED
>>> #error ...
>>> #endif
>>>
>>> at use sites?
>>
>> Rather than such a meta-define, I prefer changing the semantics of the
>> macro itself from defined/undefined to nonzero/zero, changing the users
>> from #if to if () conditionals (or ? :, as appropriate), and adding a
>> default zero definition to defaults.h along with updating all definitions,
>> users and documentation.  A meta-define seems just as error-prone as the
>> original #ifdef.
>
> I like this a lot actually.... then you can tell whether its been defined or
> not... Although I suppose it depends on when and where the non-default value
> comes from, and that it is properly included in the .c file and not missed.
> It ought to cover the vast majority of cases anyway.
>
>>
>> Similarly, for any macros with default definitions scattered around the
>> source tree rather than in defaults.h, moving them to defaults.h is a good
>> idea.
>
> I think this is also a good idea.

Or you move the macros depending on NO_DOLLARS_IN_LABELS
to tm.h itself ...

Richard.

> Andrew
>

On Fri, 15 Nov 2013, Richard Biener wrote:

> Or you move the macros depending on NO_DOLLARS_IN_LABELS
> to tm.h itself ...

I'm dubious about that for the front-end macros, but in some cases it may 
indeed make sense to move a macro that depends on target macros, rather 
than really being one itself, to defaults.h.

Here is a list of 400 target macros (some false positives likely) used in 
preprocessor conditionals outside defaults.h, libgcc and libobjc (it's 
possible some of those may *also* be used in those places) - not just 
#ifdef but also e.g. "#if TARGET_MACRO == value".  Many should be easy to 
move to defaults.h and eliminate preprocessor conditionals elsewhere, 
given appropriate automation (most of the *_SPEC macros are probably only 
used in gcc.c, for example, and have default definitions there, so those 
are cases of moving an existing default definition to an appropriately 
commented section of defaults.h).  Note that being used in code built for 
the target is not an obstacle to moving to defaults.h; it just complicates 
converting to a target hook.  However, some macros such as 
ARG_POINTER_REGNUM or SWITCHABLE_TARGET may not be really practical to 
eliminate processor conditionals on.

ADA_LONG_TYPE_SIZE
ADDITIONAL_REGISTER_NAMES
ADDR_VEC_ALIGN
ADJUST_FIELD_ALIGN
ADJUST_INSN_LENGTH
ADJUST_REG_ALLOC_ORDER
APPLY_RESULT_SIZE
ARGS_GROW_DOWNWARD
ARG_POINTER_REGNUM
ASM_COMMENT_START
ASM_DEBUG_SPEC
ASM_DECLARE_FUNCTION_NAME
ASM_DECLARE_FUNCTION_SIZE
ASM_DECLARE_OBJECT_NAME
ASM_DECLARE_REGISTER_GLOBAL
ASM_FINISH_DECLARE_OBJECT
ASM_FPRINTF_EXTENSIONS
ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX
ASM_NO_SKIP_IN_TEXT
ASM_OUTPUT_ADDR_DIFF_ELT
ASM_OUTPUT_ADDR_DIFF_VEC
ASM_OUTPUT_ADDR_VEC
ASM_OUTPUT_ADDR_VEC_ELT
ASM_OUTPUT_ALIGNED_BSS
ASM_OUTPUT_ALIGNED_COMMON
ASM_OUTPUT_ALIGNED_DECL_COMMON
ASM_OUTPUT_ALIGNED_DECL_LOCAL
ASM_OUTPUT_ALIGNED_LOCAL
ASM_OUTPUT_ALIGN_WITH_NOP
ASM_OUTPUT_CASE_END
ASM_OUTPUT_CASE_LABEL
ASM_OUTPUT_DEF
ASM_OUTPUT_DEF_FROM_DECLS
ASM_OUTPUT_DWARF_DELTA
ASM_OUTPUT_DWARF_OFFSET
ASM_OUTPUT_DWARF_PCREL
ASM_OUTPUT_DWARF_TABLE_REF
ASM_OUTPUT_DWARF_VMS_DELTA
ASM_OUTPUT_EXTERNAL
ASM_OUTPUT_EXTERNAL_LIBCALL
ASM_OUTPUT_FDESC
ASM_OUTPUT_LABEL_REF
ASM_OUTPUT_MAX_SKIP_ALIGN
ASM_OUTPUT_OPCODE
ASM_OUTPUT_POOL_PROLOGUE
ASM_OUTPUT_REG_PUSH
ASM_OUTPUT_SOURCE_FILENAME
ASM_OUTPUT_SPECIAL_POOL_ENTRY
ASM_OUTPUT_SYMBOL_REF
ASM_OUTPUT_TLS_COMMON
ASM_OUTPUT_TYPE_DIRECTIVE
ASM_OUTPUT_WEAKREF
ASM_OUTPUT_WEAK_ALIAS
ASM_SPEC
ASM_WEAKEN_DECL
ASM_WEAKEN_LABEL
ASSEMBLER_DIALECT
AS_NEEDS_DASH_FOR_PIPED_INPUT
AVOID_CCMODE_COPIES
BIGGEST_FIELD_ALIGNMENT
BITFIELD_NBYTES_LIMITED
BITS_PER_UNIT
BLOCK_REG_PADDING
BSS_SECTION_ASM_OP
CALL_POPS_ARGS
CALL_REALLY_USED_REGISTERS
CANNOT_CHANGE_MODE_CLASS
CASE_VECTOR_SHORTEN_MODE
CC1PLUS_SPEC
CC1_SPEC
CC_STATUS_INIT
CC_STATUS_MDEP
CC_STATUS_MDEP_INIT
CHAR_TYPE_SIZE
CLASS_MAX_NREGS
CLEAR_BY_PIECES_P
CLEAR_INSN_CACHE
COLLECT_EXPORT_LIST
COLLECT_RUN_DSYMUTIL
COLLECT_SHARED_FINI_FUNC
COLLECT_SHARED_INIT_FUNC
CONSTANT_ALIGNMENT
CONSTANT_POOL_BEFORE_FUNCTION
CPLUSPLUS_CPP_SPEC
CPP_SPEC
CTORS_SECTION_ASM_OP
C_COMMON_OVERRIDE_OPTIONS
DATA_ABI_ALIGNMENT
DATA_ALIGNMENT
DATA_SECTION_ASM_OP
DBR_OUTPUT_SEQEND
DBX_BLOCKS_FUNCTION_RELATIVE
DBX_CONTIN_CHAR
DBX_CONTIN_LENGTH
DBX_DEBUGGING_INFO
DBX_FUNCTION_FIRST
DBX_LINES_FUNCTION_RELATIVE
DBX_NO_XREFS
DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END
DBX_OUTPUT_SOURCE_LINE
DBX_STATIC_STAB_DATA_SECTION
DBX_USE_BINCL
DEBUGGER_ARG_OFFSET
DEBUGGER_AUTO_OFFSET
DEBUG_ABBREV_SECTION
DEBUG_ARANGES_SECTION
DEBUG_FRAME_SECTION
DEBUG_INFO_SECTION
DEBUG_LINE_SECTION
DEBUG_LOC_SECTION
DEBUG_MACINFO_SECTION
DEBUG_MACRO_SECTION
DEBUG_PUBNAMES_SECTION
DEBUG_PUBTYPES_SECTION
DEBUG_RANGES_SECTION
DEBUG_STR_SECTION
DOLLARS_IN_IDENTIFIERS
DONT_USE_BUILTIN_SETJMP
DRIVER_SELF_SPECS
DTORS_SECTION_ASM_OP
DWARF2_ASM_LINE_DEBUG_INFO
DWARF2_DEBUGGING_INFO
DWARF2_FRAME_INFO
DWARF2_UNWIND_INFO
DWARF_ALT_FRAME_RETURN_COLUMN
DWARF_FRAME_REGNUM
DYNAMIC_CHAIN_ADDRESS
EH_FRAME_SECTION_NAME
EH_RETURN_DATA_REGNO
EH_RETURN_HANDLER_RTX
EH_RETURN_STACKADJ_RTX
EH_USES
ELF_ASCII_ESCAPES
ELIMINABLE_REGS
EMPTY_FIELD_BOUNDARY
ENDFILE_SPEC
EPILOGUE_USES
EXTRA_CONSTRAINT_STR
EXTRA_SPECS
EXTRA_SPEC_FUNCTIONS
FENCE_FOLLOWING_MOVNT
FINAL_PRESCAN_INSN
FIND_BASE_TERM
FIRST_PSEUDO_REGISTER
FLOAT_STORE_FLAG_VALUE
FLOAT_WORDS_BIG_ENDIAN
FRAME_ADDR_RTX
FRAME_BEGIN_LABEL
FRAME_POINTER_CFA_OFFSET
FRAME_POINTER_REGNUM
FUNCTION_ARG_OFFSET
FUNCTION_VALUE
FUNCTION_VALUE_REGNO_P
GCC_DRIVER_HOST_INITIALIZATION
GCC_INCLUDE_DIR
GLOBAL_ASM_OP
GOMP_SELF_SPECS
GO_IF_LEGITIMATE_ADDRESS
GPLUSPLUS_INCLUDE_DIR
GTM_SELF_SPECS
HANDLE_PRAGMA_PACK_WITH_EXPANSION
HARD_FRAME_POINTER_IS_ARG_POINTER
HARD_FRAME_POINTER_IS_FRAME_POINTER
HARD_FRAME_POINTER_REGNUM
HARD_REGNO_CALLER_SAVE_MODE
HARD_REGNO_CALL_PART_CLOBBERED
HARD_REGNO_RENAME_OK
HAS_INIT_SECTION
HAVE_AS_LEB128
HAVE_POST_DECREMENT
HAVE_POST_INCREMENT
HAVE_POST_MODIFY_DISP
HAVE_POST_MODIFY_REG
HAVE_PRE_DECREMENT
HAVE_PRE_INCREMENT
HAVE_PRE_MODIFY_DISP
HAVE_PRE_MODIFY_REG
HONOR_REG_ALLOC_ORDER
IFCVT_MACHDEP_INIT
IFCVT_MODIFY_CANCEL
IFCVT_MODIFY_FINAL
IFCVT_MODIFY_INSN
IFCVT_MODIFY_MULTIPLE_TESTS
IFCVT_MODIFY_TESTS
IMMEDIATE_PREFIX
INCLUDE_DEFAULTS
INCOMING_RETURN_ADDR_RTX
INITIAL_FRAME_ADDRESS_RTX
INIT_ARRAY_SECTION_ASM_OP
INIT_CUMULATIVE_INCOMING_ARGS
INIT_CUMULATIVE_LIBCALL_ARGS
INIT_ENVIRONMENT
INIT_EXPANDERS
INIT_SECTION_ASM_OP
INSN_LENGTH_ALIGNMENT
INSN_REFERENCES_ARE_DELAYED
INSN_SETS_ARE_DELAYED
INT_TYPE_SIZE
INVOKE__main
IRA_HARD_REGNO_ADD_COST_MULTIPLIER
IS_ASM_LOGICAL_LINE_SEPARATOR
JCR_SECTION_NAME
JMP_BUF_SIZE
JUMP_ALIGN
JUMP_TABLES_IN_TEXT_SECTION
LABEL_ALIGN
LABEL_ALIGN_AFTER_BARRIER
LDD_SUFFIX
LD_FINI_SWITCH
LD_INIT_SWITCH
LEAF_REGISTERS
LEAF_REG_REMAP
LEGITIMIZE_RELOAD_ADDRESS
LIBASAN_EARLY_SPEC
LIBCALL_VALUE
LIBGCC2_HAS_TF_MODE
LIBGCC_SPEC
LIBSTDCXX
LIBSTDCXX_STATIC
LIBTSAN_EARLY_SPEC
LIB_SPEC
LIMIT_RELOAD_CLASS
LINK_COMMAND_SPEC
LINK_EH_SPEC
LINK_GCC_C_SEQUENCE_SPEC
LINK_LIBGCC_SPECIAL_1
LINK_SPEC
LINK_SSP_SPEC
LOAD_EXTEND_OP
LOCAL_LABEL_PREFIX
LOGICAL_OP_NON_SHORT_CIRCUIT
LONG_LONG_TYPE_SIZE
LOOP_ALIGN
MAIN_STACK_BOUNDARY
MAKE_DECL_ONE_ONLY
MASK_RETURN_ADDR
MATH_LIBRARY
MATH_LIBRARY_PROFILE
MAX_CONDITIONAL_EXECUTE
MAX_OFILE_ALIGNMENT
MD_CAN_REDIRECT_BRANCH
MD_EXEC_PREFIX
MD_STARTFILE_PREFIX
MD_STARTFILE_PREFIX_1
MEMORY_MOVE_COST
MINIMUM_ATOMIC_ALIGNMENT
MODE_AFTER
MODE_BASE_REG_CLASS
MODE_BASE_REG_REG_CLASS
MODE_CODE_BASE_REG_CLASS
MODE_ENTRY
MODE_EXIT
MODIFY_JNI_METHOD_CALL
MOVE_BY_PIECES_P
MULTILIB_DEFAULTS
MY_ISCOFF
NAME__MAIN
NATIVE_SYSTEM_HEADER_COMPONENT
NATIVE_SYSTEM_HEADER_DIR
NEXT_OBJC_RUNTIME
NM_FLAGS
NO_DBX_BNSYM_ENSYM
NO_DOLLAR_IN_LABEL
NO_DOT_IN_LABEL
NO_FUNCTION_CSE
NO_IMPLICIT_EXTERN_C
NO_PROFILE_COUNTERS
OBJC_GEN_METHOD_LABEL
OBJC_JBLEN
OBJECT_FORMAT_COFF
OBJECT_FORMAT_ELF
OFFS_ASSIGNIVAR_FAST
OFFS_MSGSEND_FAST
OPTIMIZE_MODE_SWITCHING
OPTION_DEFAULT_SPECS
OUTPUT_QUOTED_STRING
OVERLAPPING_REGISTER_NAMES
OVERRIDE_ABI_FORMAT
PAD_VARARGS_DOWN
PARM_BOUNDARY
PCC_BITFIELD_TYPE_MATTERS
PCC_STATIC_STRUCT_RETURN
PIC_CASE_VECTOR_ADDRESS
PIC_OFFSET_TABLE_REGNUM
POINTERS_EXTEND_UNSIGNED
PREFERRED_RELOAD_CLASS
PRINT_OPERAND
PRINT_OPERAND_ADDRESS
PRINT_OPERAND_PUNCT_VALID_P
PROFILE_BEFORE_PROLOGUE
PROFILE_HOOK
PROMOTE_MODE
PUSH_ARGS_REVERSED
PUSH_ROUNDING
READONLY_DATA_SECTION_ASM_OP
READ_CAN_USE_WRITE_PREFETCH
REAL_LIBGCC_SPEC
REAL_NM_FILE_NAME
REGISTER_MOVE_COST
REGISTER_PREFIX
REGISTER_TARGET_PRAGMAS
REGMODE_NATURAL_SIZE
REGNO_MODE_CODE_OK_FOR_BASE_P
REGNO_MODE_OK_FOR_BASE_P
REGNO_MODE_OK_FOR_REG_BASE_P
REG_ALLOC_ORDER
REG_PARM_STACK_SPACE
RELATIVE_PREFIX_NOT_LINKDIR
RETURN_ADDRESS_POINTER_REGNUM
RETURN_ADDR_IN_PREVIOUS_FRAME
RETURN_ADDR_OFFSET
RETURN_ADDR_RTX
REVERSE_CONDITION
ROUND_TYPE_ALIGN
SBSS_SECTION_ASM_OP
SDATA_SECTION_ASM_OP
SDB_ALLOW_FORWARD_REFERENCES
SDB_ALLOW_UNKNOWN_REFERENCES
SDB_DEBUGGING_INFO
SECONDARY_INPUT_RELOAD_CLASS
SECONDARY_MEMORY_NEEDED
SECONDARY_MEMORY_NEEDED_MODE
SECONDARY_MEMORY_NEEDED_RTX
SECONDARY_OUTPUT_RELOAD_CLASS
SECONDARY_RELOAD_CLASS
SELECT_CC_MODE
SETUP_FRAME_ADDRESSES
SET_BY_PIECES_P
SHLIB_SUFFIX
SHORT_IMMEDIATES_SIGN_EXTEND
SPARC_STACK_BOUNDARY_HACK
STACK_ALIGNMENT_NEEDED
STACK_BOUNDARY
STACK_DYNAMIC_OFFSET
STACK_GROWS_DOWNWARD
STACK_PARMS_IN_REG_PARM_AREA
STACK_POINTER_OFFSET
STACK_POP_CODE
STACK_PUSH_CODE
STACK_REGS
STANDARD_STARTFILE_PREFIX_1
STANDARD_STARTFILE_PREFIX_2
STARTFILE_PREFIX_SPEC
STARTFILE_SPEC
STATIC_CHAIN_INCOMING_REGNUM
STATIC_CHAIN_REGNUM
STATIC_LIBASAN_LIBS
STATIC_LIBTSAN_LIBS
STDC_0_IN_SYSTEM_HEADERS
STORE_BY_PIECES_P
STORE_FLAG_VALUE
STRUCTURE_SIZE_BOUNDARY
SUPPORTS_WEAK
SWITCHABLE_TARGET
SYSROOT_SUFFIX_SPEC
TARGET_64BIT
TARGET_ABI_OPEN_VMS
TARGET_AIX_VERSION
TARGET_ALIGN_NATURAL
TARGET_ASM_CONSTRUCTOR
TARGET_ASM_DESTRUCTOR
TARGET_ASM_NAMED_SECTION
TARGET_ASM_OUTPUT_ANCHOR
TARGET_CAN_SPLIT_STACK
TARGET_CPU_CPP_BUILTINS
TARGET_DLLIMPORT_DECL_ATTRIBUTES
TARGET_EDOM
TARGET_EXECUTABLE_SUFFIX
TARGET_EXTRA_INCLUDES
TARGET_EXTRA_PRE_INCLUDES
TARGET_FORMAT_TYPES
TARGET_HAVE_CTORS_DTORS
TARGET_OBJECT_SUFFIX
TARGET_OBJFMT_CPP_BUILTINS
TARGET_OPTF
TARGET_OS_CPP_BUILTINS
TARGET_OVERRIDES_FORMAT_ATTRIBUTES
TARGET_OVERRIDES_FORMAT_INIT
TARGET_POSIX_IO
TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DATA_T
TARGET_TERMINATE_DW2_EH_FRAME_INFO
TARGET_VXWORKS_RTP
TEXT_SECTION_ASM_OP
THREAD_MODEL_SPEC
TRAMPOLINE_SECTION
USE_LD_AS_NEEDED
USE_LOAD_POST_DECREMENT
USE_LOAD_POST_INCREMENT
USE_LOAD_PRE_DECREMENT
USE_LOAD_PRE_INCREMENT
USE_MD_CONSTRAINTS
USE_SELECT_SECTION_FOR_FUNCTIONS
USE_STORE_POST_DECREMENT
USE_STORE_POST_INCREMENT
USE_STORE_PRE_DECREMENT
USE_STORE_PRE_INCREMENT
VMS_DEBUGGING_INFO
WIDEST_HARDWARE_FP_SIZE
WORD_REGISTER_OPERATIONS
XCOFF_DEBUGGING_INFO