This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for builtins.h restructuring [1/2]

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

OK for trunk?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]