This is the mail archive of the gcc-patches@gcc.gnu.org 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] tree-eh.c prototypes


On Wed, Oct 2, 2013 at 7:54 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
> This patch moves the prototypes for tree-eh.c into a new file tree-eh.h.
> This file is in fact really gimple-eh.. we'll rename that later with the
> other tree->gimple renaming that is needed.
>
> however, using_eh_for_cleanups() is in fact a front end routine which is
> called when eh regions are used for cleanups. It sets a static flag in
> tree-eh.c and is only examined from one place in tree-eh.c.  I think 4 or 5
> of the front ends call this routine.
>
> Since this is really a front end interface routine, I kept the name and
> moved it and the static variable to tree.[ch] for now and added a query
> routine. This prevents the front ends from having to include any of this
> gimple stuff.
>
> Bootstraps onx86_64-unknown-linux-gnu and has no new regressions. OK?

Ok.

Thanks,
Richard.

> Andrew
>
> PS.  do we want to put debug routines in the .h file?  I ask because I see a
> few are, but in many other cases there are a number of them in the .c file
> which are not explicitly exported.  Often their names aren't very useful
> either and sometimes sometimes utilize structs or types that are specific to
> that .c file.   Mostly I think they are not static simply because the
> debugger needs them so the compiler wont throw them away.
>
> for instance, tree-ssa-pre.c has 3 of them, including a very common form:
> debug_bitmap_sets_for_bb(basic_block bb)...  This prints a bitmaps based on
> internal meanings of the bits. I see numerous other files which have
> similar, if slightly different names to do a simiiar function
> And in fact, tree-ssa-pre.c will have no header file, unless we need a place
> to put these 3 debug files.
>
> My personal preference is to simply leave them in the .c file, mostly
> because they can have internal types.  Ideally, all the prototypes would be
> listed early in the .c file in one place so anyone truing to debug something
> can find them easily.

The implementation should be marked with DEBUG_FUNCTION, the
header declarations are in place since in C days we required
strict prototypes.  I'd vote for removing the declarations in header files.

Richard.


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