This is the mail archive of the
mailing list for the GCC project.
Re: [patch] tree-eh.c prototypes
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 8 Oct 2013 12:14:31 +0200
- Subject: Re: [patch] tree-eh.c prototypes
- Authentication-results: sourceware.org; auth=none
- References: <524C5DE0 dot 3060601 at redhat dot com>
On Wed, Oct 2, 2013 at 7:54 PM, Andrew MacLeod <email@example.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?
> 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.