On 06/02/14 09:26, Andrew MacLeod wrote:
Furthering the include file restructuring, this patch fixes the header
files for builtins.h. The prototypes were spread between tree.h, expr.h
and fold-const.h.
* There were 5 build_* routines in builtins.c that really should be in
tree.c. They are used all over the place. The prototypes were already
in tree.h.
* There were 3 routines in builtins.c that belonged in targhooks.c.
The prototypes were already in targhooks.h
* fold-const.c uses do_mpc_arg2() which is defined in builtins.c, so the
prototype should be in builtins.h. The prototype utilizes type
mpc_srcptr from <mpc.h> which means that every file which includes
builtins.h would also require #include <mpc.h>. That is likely the
reason the prototype was placed into realmpfr.h. I added #include
<mpc.h> to builtins.h. Normally we're trying not to do that until we
can rebuild a decent module structure, but I think that rule only makes
sense for include files within gcc's source base...
Seems reasonable.
* Finally, fortran/trans.c was calling fold_builtin_call_array directly.
That means it would have needed builtins.h which caused issues since
builtins.h defines struct target_builtins and uses
FIRST_PSEUDO_REGISTER... which is defined within the target config
file... something I dont think we really want to expose to the fortran
front end :-P. Anyway, looking aorund, it turns out
fold-const.c::fold_build_call_array_loc is really a wrapper for a call
to fold_builtin_call_array, with some extra checking code before and
after the call protected by ENABLE_FOLD_CHECKING. I'd think that should
be OK since its what other front ends call...
Ick. Yea, it'd be good if FIRST_PSEUDO_REGISTER doesn't bleed all the
way into the front-ends.
Bootstraps on x86_64-unknown-linux-gnu with no regressions. I also ran
it through a full set of target builds for compilation, with no new
failures there.
The second set of patches are the updated #includes required for
compilation.
OK for trunk?
OK.
jeff
