In doing up the mods for the constant wide int code, we found a nasty including
ordering problem that seems only tangentially related to our code. In
options.h this is generated:
/* Anything that includes tm.h, does not necessarily need this. */
#if !defined(GCC_TM_H)
#include "input.h" /* for location_t */
bool
common_handle_option_auto (struct gcc_options *opts,
struct gcc_options *opts_set,
const struct cl_decoded_option *decoded,
unsigned int lang_mask, int kind,
location_t loc,
const struct cl_option_handlers *handlers,
diagnostic_context *dc);
and produces a nasty dependency on include ordering that's annoying to track
down as it fails only in the C++ bootstrap. If one includes tm.h first, then
c-opts.c doesn't compile with C++ but does with C. If one adds a #include
"options.h" before the #include "tm.h", then things are fine. :-( Changing
the contents of the include based upon something as trivial as the include
ordering is, nasty. So, that said, in a new file we'll be submitting shortly
to handle wide int constants (wide-int.h), we have a #include "tm.h", and we
don't use options.h, but without a #include of options.h first, c-opts.c won't
compile. Needless to say, tree.h will include the wide-int.h header file...
I'm sure this was engineered to work in come fashion, but, that escapes me,
what is the correct dance ensure the prototypes in options.h are present?
Include options.h at the top of c-opts.c, to ensure it comes before tree.h
(which is the file that includes the wide-int.h header, include options.h in
wide-int.h?
