original tree for folded expressions

[Joachim Wieland]

I'm working on a plugin to report dependencies of a .c file to its
headers, i.e. what information from the headers is referenced from the
.c file.

This works pretty well for most stuff, but I really have a hard time
for anything that gets folded to a constant. The AST does no longer
have the original types/functions/constants but transforms them to
const ints in an early stage already.

I am looking at the AST from a plugin and a tree walking function
called from PLUGIN_PRE_GENERICIZE. Is there an earlier phase that I
could hook into? If not, would it be acceptable to add the original
tree to a folded tree for analyzing tools like mine? If so, any hint
about how this can be implemented? From looking at it, it seems that
everything (?) is passed through fold_convert_loc.


Thanks

Re: original tree for folded expressions

[Joachim Wieland]

On Fri, Sep 16, 2011 at 1:37 PM, Diego Novillo  wrote:
> However, you could try an approach similar to what Le-Chun implemented for
> -Wself-assign (which only exists in the google/main branch for now).  See
> EXPR_FOLDED in http://gcc.gnu.org/ml/gcc-patches/2011-04/msg01898.html.

Hm, I don't see how exactly this would solve my problem... The issue I
am facing is that references to necessary header files are optimized
away. Just knowing that an expression has been folded doesn't help
me... :-(

What I had in mind was to only keep additional copies of the original
subtrees if the node has been replaced completely by folding. I don't
see why memory consumption would go through the roof that way, this
would mean that a very high percentage of the code can be folded and
shrinked significantly which shouldn't be true in the general case. Of
course I see that it can be difficult to implement this, it might
require changes to every folding function.

Is there any function that I could create a hook for which still sees
an unfolded expression?

Thanks,
Joachim

how to output function prototypes from a plugin

[Joachim Wieland]

I am writing a plugin that should dump out function declarations and
definitions as the compiler sees them. One thing that I noticed
(besides that Brian Hackett's PLUGIN_FINISH_DECL hook should really be
applied to future versions) was that there does not seem to be a
function that could output the full prototype of a function in a
standardized form.

I found lhd_decl_printable_name() which only gives me the name but not
the full declaration and there are some pretty printer routines for C
in c-pretty-print.c and tree-pretty-print.c and for C++ it seems that
what I need lives in cp/error.c. All of those functions are static...

Have I missed anything?

Thank you very much,
Joachim

wrong output of print_generic_decl() called from a plugin

[Joachim Wieland]

While testing how to parse C and C++ code for function prototypes from a plugin

(see http://gcc.gnu.org/ml/gcc/2010-12/msg00179.html)

I noticed that print_generic_decl() seems to output wrong data.

Consider the following function definition:

--
void barfunc (int foo, int abc, ... ) {

}
--

This outputs "static void barfunc (int);" but the function is neither
static nor does it expect only one int parameter...

Am I doing something wrong? I am calling "print_generic_decl(file,
decl, 0);" from the PLUGIN_PRE_GENERICIZE hook and this is gcc version
4.5.1 (GCC) on Solaris.


Thanks,
Joachim

Re: wrong output of print_generic_decl() called from a plugin

[Joachim Wieland]

On Wed, Dec 8, 2010 at 1:52 PM, I wrote:
> This outputs "static void barfunc (int);" but the function is neither
> static nor does it expect only one int parameter...

here's another example where print_generic_decl() fails:

---
typedef void (*Handler)( int , void * );
Handler GetFunctionPointer();
---

This would output "extern void (*Handler) (int, void *)
GetFunctionPointer (void);"

Any other function I could use that is more reliable?


Thanks,
Joachim

PLUGIN_FINISH_TYPE not executed for enums

[Joachim Wieland]

Hi,

is there any reason why in gcc-4.5.1 the plugin hook
PLUGIN_FINISH_TYPE is not executed for enums?

In c-parser.c there is a call to

invoke_plugin_callbacks (PLUGIN_FINISH_TYPE, t.spec);

for RID_STRUCT and RID_UNION but not for RID_ENUM. Is this an
oversight or on purpose?


Thanks,
Joachim