This is the mail archive of the
mailing list for the GCC project.
Re: Patch for builtins.h restructuring [1/2]
- From: Jeff Law <law at redhat dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 02 Jun 2014 11:30:56 -0600
- Subject: Re: Patch for builtins.h restructuring [1/2]
- Authentication-results: sourceware.org; auth=none
- References: <538C9790 dot 2070006 at redhat dot com>
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
* 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
* 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...
Ick. Yea, it'd be good if FIRST_PSEUDO_REGISTER doesn't bleed all the
way into the front-ends.
* 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...
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
The second set of patches are the updated #includes required for
OK for trunk?