https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111021
--- Comment #14 from Kewen Lin <linkw at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #13)
> (In reply to Richard Biener from comment #12)
> > I think a "too broad" dependence isn't bad. The cris specific solution also
> > looks manageable, though I wonder what's special about x-protos.h, knowing
> > very little of that area.
>
> Thanks for the comments, I'll follow up with the former if no objections. :)
>
> About {port}-protos.h, the documentation says "The ‘machine.h’ header is
> included very early in GCC’s standard sequence of header files, while
> ‘machine-protos.h’ is included late in the sequence. Thus ‘machine-protos.h’
> can include declarations referencing types that are not defined when
> ‘machine.h’ is included, specifically including those from ‘rtl.h’ and
> ‘tree.h’."
insn-automata.cc have both tm.h ($port.h) and tm_p.h (${port}-protos.h), the
order looks like:
#define IN_TARGET_CODE 1
#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"
#include "alias.h"
#include "tree.h"
#include "varasm.h"
#include "stor-layout.h"
#include "calls.h"
#include "rtl.h"
#include "memmodel.h"
#include "tm_p.h"
#include "insn-config.h"
#include "recog.h"
#include "regs.h"
#include "output.h"
#include "insn-attr.h"
#include "diagnostic-core.h"
#include "flags.h"
#include "function.h"
#include "emit-rtl.h"
