[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #31 from Richard Biener --- Original issue was fixed. Please open a new bugreport if there's an issue you think should be fixed on current trunk preferably without a plugin but using some -fdump-* functions. There's now -fdump-tree-*-gimple which should yield (roughly) compilable code with -fgimple. At least the function definitions should have the correct prototypes. Your last testcase (on Linux, don't have accces to Solaris) gets me in t.c.004t.gimple with -fdump-tree-gimple-gimple void __GIMPLE () foo (char * const buf, const int bufsz) { } which looks fine.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #30 from Eric Gallager --- (In reply to rguent...@suse.de from comment #26) > On Wed, 16 Mar 2011, joe at mcknight dot de wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 > > > > --- Comment #25 from joe at mcknight dot de 2011-03-16 12:58:50 UTC --- > > (In reply to comment #24) > > > > > Well, it confirmed that void_list_node is not used, but I can't > > > reproduce this fact. > > > > Then how should we go on with this? As said, I can also only reproduce it > > under > > very special circumstances but unfortunately these were the default > > circumstances for our compiler runs. > > You should try to debug this yourself then. > > > Can we use anything else to terminate the loop? Is there any other debug > > output > > that would be helpful for you? > > Well, try to figure out who creates that void_list_node clone. > > You can use !VOID_TYPE_P (TREE_VALUE (arg)) instead. > > Richard. So, if the responsibility is on Joe to debug, does it make sense for you to still be the assignee then?
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.0 |---
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #29 from joe at mcknight dot de 2011-04-06 17:55:30 UTC --- FWIW, I can reproduce this now on Solaris without any magic compiler switches: The program is just this here: --- void foo(char *buf, int bufsz); void foo(char * const buf, const int bufsz) { } --- Compiling with just gcc -fplugin=/path/to/plugin/testplugin.so -c foo.c (gcc 4.5.2 with your patch on sparc-sun-solaris2.10) gives me: static void foo (char * const, int, void, ...); However it only shows up on Solaris, I tried it on a Linux installation I have as well and I get the correct output there :-( Note the differences between the declaration and the definition regarding const. If I remove any const in the definition (for buf or bufsz) or add a const to the declaration, the output will be correct.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 joe at mcknight dot de changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #28 from joe at mcknight dot de 2011-03-17 20:03:59 UTC --- Reopening, to document and keep track of the fact that at least one corner case produces wrong output with the applied patch.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #24 from rguenther at suse dot de rguenther at suse dot de 2011-03-16 09:38:37 UTC --- On Tue, 15 Mar 2011, joe at mcknight dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #23 from joe at mcknight dot de 2011-03-15 17:05:24 UTC --- (In reply to comment #22) Compare it to: typedef int mytype; int myfunc2(mytype var) { return 1; }; which outputs static int myfunc2 (mytype); i.e. returns the newly created type as well. That's by design. Then what is the design rule behind it, for me it looks inconsistent to once inline the original type and another time use the newly created type. It outputs static void (*Handler) (int, void *) GetFunctionPointer (void); It's not designed to do that. The functions are for debugging and diagnostic output only, they are not supposed to generate valid C. I know, but instead of creating a new language, wouldn't it be good to just stick to the C grammar to describe what is being seen? Was the debug output helpful with respect to the wrong variadic output? Well, it confirmed that void_list_node is not used, but I can't reproduce this fact.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #25 from joe at mcknight dot de 2011-03-16 12:58:50 UTC --- (In reply to comment #24) Well, it confirmed that void_list_node is not used, but I can't reproduce this fact. Then how should we go on with this? As said, I can also only reproduce it under very special circumstances but unfortunately these were the default circumstances for our compiler runs. Can we use anything else to terminate the loop? Is there any other debug output that would be helpful for you? Thanks!
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #26 from rguenther at suse dot de rguenther at suse dot de 2011-03-16 13:07:03 UTC --- On Wed, 16 Mar 2011, joe at mcknight dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #25 from joe at mcknight dot de 2011-03-16 12:58:50 UTC --- (In reply to comment #24) Well, it confirmed that void_list_node is not used, but I can't reproduce this fact. Then how should we go on with this? As said, I can also only reproduce it under very special circumstances but unfortunately these were the default circumstances for our compiler runs. You should try to debug this yourself then. Can we use anything else to terminate the loop? Is there any other debug output that would be helpful for you? Well, try to figure out who creates that void_list_node clone. You can use !VOID_TYPE_P (TREE_VALUE (arg)) instead. Richard.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #27 from joe at mcknight dot de 2011-03-16 14:40:32 UTC --- (In reply to comment #26) Can we use anything else to terminate the loop? Is there any other debug output that would be helpful for you? Well, try to figure out who creates that void_list_node clone. You can use !VOID_TYPE_P (TREE_VALUE (arg)) instead. This works for that special case. Also checking for TREE_CHAIN(arg) != NULL works.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-15 13:39:50 UTC --- Author: rguenth Date: Tue Mar 15 13:39:28 2011 New Revision: 170995 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=170995 Log: 2011-03-15 Richard Guenther rguent...@suse.de PR middle-end/47650 * tree-pretty-print.c (dump_function_declaration): Properly dump unprototyped and varargs function types. * gfortran.dg/c_f_pointer_tests_3.f90: Adjust. * gfortran.dg/ishft_4.f90: Likewise. * gfortran.dg/leadz_trailz_3.f90: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/c_f_pointer_tests_3.f90 trunk/gcc/testsuite/gfortran.dg/ishft_4.f90 trunk/gcc/testsuite/gfortran.dg/leadz_trailz_3.f90 trunk/gcc/tree-pretty-print.c
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #15 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-15 13:41:02 UTC --- Fixed.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #16 from joe at mcknight dot de 2011-03-15 15:52:01 UTC --- Created attachment 23665 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23665 dump_function_declaration with debug
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #17 from joe at mcknight dot de 2011-03-15 15:53:23 UTC --- Created attachment 23666 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23666 debug output from a run of the modified function
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #18 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-15 15:56:04 UTC --- comment #13 would happen if the list of argument types is not terminated by the shared tree node void_list_node but by a clone. We expect the shared void_list_node to be used elsewhere as well.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-15 15:59:44 UTC --- All looks good to me with your C testcase: gcc gdb --args ./cc1 -quiet t.i (gdb) b gimplify_function_tree Breakpoint 5 at 0x855ac4: file /space/rguenther/src/svn/trunk/gcc/gimplify.c, line 7820. (gdb) run Breakpoint 5, gimplify_function_tree (fndecl=0x75b49000) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7820 7820 gcc_assert (!gimple_body (fndecl)); (gdb) call debug_generic_expr (fndecl-common.type) int T357 (struct { double dvar; int ivar; } *) (gdb) call debug_generic_expr (fndecl) myfunc (gdb) c Continuing. Breakpoint 5, gimplify_function_tree (fndecl=0x75b29f00) at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7820 7820 gcc_assert (!gimple_body (fndecl)); (gdb) call debug_generic_expr (fndecl) GetFunctionPointer (gdb) call debug_generic_expr (fndecl-common.type) void (*Handler) (int, void *) T352 (void) (gdb) c Continuing. Breakpoint 3, 0x763ca250 in exit () from /lib64/libc.so.6
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #20 from joe at mcknight dot de 2011-03-15 16:03:23 UTC --- Unfortunately I cannot confirm that this bug is fixed, so I need to reopen it. For one thing this bug is not only about variadic functions, but dump_function_declaration() returns wrong output also for other cases as described, like functions involving function pointers and typedef'ed structs. Second I am still seeing the issue described earlier, where a function now returns a variadic function even though there is none. I have modified the function to print debug output to a file and I am attaching both the modified function and its debug output. For me it looks like the arg != void_list_node does not work, so the while loop is executed once more, printing the void and then arg goes NULL, the loop is left and since arg is NULL, the function prints , ... at the end. Let me know if there is anything else I can do to help.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #21 from joe at mcknight dot de 2011-03-15 16:18:37 UTC --- (In reply to comment #19) All looks good to me with your C testcase: (gdb) call debug_generic_expr (fndecl-common.type) int T357 (struct { double dvar; int ivar; } *) Hm, the function was declared to take a new type tpdefp, so I was expecting the dump to return it like this and not resolve it to whatever it is typedef'ed to. Compare it to: typedef int mytype; int myfunc2(mytype var) { return 1; }; which outputs static int myfunc2 (mytype); i.e. returns the newly created type as well. (gdb) call debug_generic_expr (fndecl-common.type) void (*Handler) (int, void *) T352 (void) It outputs static void (*Handler) (int, void *) GetFunctionPointer (void); And this is not C :-) The compiler throws a parse error when I compile a function with the prototype that it outputs.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #22 from rguenther at suse dot de rguenther at suse dot de 2011-03-15 16:33:09 UTC --- On Tue, 15 Mar 2011, joe at mcknight dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #21 from joe at mcknight dot de 2011-03-15 16:18:37 UTC --- (In reply to comment #19) All looks good to me with your C testcase: (gdb) call debug_generic_expr (fndecl-common.type) int T357 (struct { double dvar; int ivar; } *) Hm, the function was declared to take a new type tpdefp, so I was expecting the dump to return it like this and not resolve it to whatever it is typedef'ed to. Compare it to: typedef int mytype; int myfunc2(mytype var) { return 1; }; which outputs static int myfunc2 (mytype); i.e. returns the newly created type as well. That's by design. (gdb) call debug_generic_expr (fndecl-common.type) void (*Handler) (int, void *) T352 (void) It outputs static void (*Handler) (int, void *) GetFunctionPointer (void); And this is not C :-) The compiler throws a parse error when I compile a function with the prototype that it outputs. It's not designed to do that. The functions are for debugging and diagnostic output only, they are not supposed to generate valid C. Richard.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #23 from joe at mcknight dot de 2011-03-15 17:05:24 UTC --- (In reply to comment #22) Compare it to: typedef int mytype; int myfunc2(mytype var) { return 1; }; which outputs static int myfunc2 (mytype); i.e. returns the newly created type as well. That's by design. Then what is the design rule behind it, for me it looks inconsistent to once inline the original type and another time use the newly created type. It outputs static void (*Handler) (int, void *) GetFunctionPointer (void); It's not designed to do that. The functions are for debugging and diagnostic output only, they are not supposed to generate valid C. I know, but instead of creating a new language, wouldn't it be good to just stick to the C grammar to describe what is being seen? Was the debug output helpful with respect to the wrong variadic output? thanks!
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #13 from joe at mcknight dot de 2011-02-10 22:50:51 UTC --- (In reply to comment #6) See http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00956.html for a patch (queued for 4.7, several tree-dump check testcases have to be adjusted). Okay, this is a bit of voodoo now, but I am getting failures of this patch in very special circumstances. I have narrowed it down to a small test program. If I compile the following program with the previously posted testplugin: typedef unsigned long size_t; extern char *strncpy(char *restrict, const char *restrict, size_t); char* strncpy0(char* dst, const char* src, size_t n) { return abc; } char* strncat0(char* dst, const char* src, size_t n) { return abc; } then I get the following output: static char * strncpy0 (char *, const char *, size_t, void, ...); static char * strncat0 (char *, const char *, size_t, void, ...); meaning that the plugin is a bit over-enthusiastic about putting I am compiling on Solaris with: gcc -O0 -fplugin=testplugin.so -std=gnu99 -m64 -S -o out.o out.c (and this doesn't show up if I either drop the -std=gnu99 or the -m64. It also doesn't show up if I drop the strncpy prototype from the example program. Nor does it if I remove both restrict keywords, I can remove one restrict however... Have I mentioned already that this reminds me a bit of voodoo? :-)...)
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.02.09 10:40:36 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-02-09 10:40:36 UTC --- See http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00956.html for a patch (queued for 4.7, several tree-dump check testcases have to be adjusted).
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #7 from joe at mcknight dot de 2011-02-09 14:22:48 UTC --- (In reply to comment #6) See http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00956.html for a patch (queued for 4.7, several tree-dump check testcases have to be adjusted). Cool, I can confirm that this fixes the example that I brought up in the beginning! :-) Now the remaining issue is wrong (non-C) output for function declarations with function pointers. Thanks!
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #8 from joe at mcknight dot de 2011-02-09 16:23:44 UTC --- (In reply to comment #6) See http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00956.html for a patch (queued for 4.7, several tree-dump check testcases have to be adjusted). Richard, I've found another example for incorrect output of print_generic_decl(). Here: typedef struct { double dvar; int ivar; } *tpdefp; int myfunc(tpdefp var); The output would not treat the variable as being of the new type but it would repeat the declaration of the struct in print_generic_decl() and output (including newlines): extern int myfunc (struct { double dvar; int ivar; } *); That could be related to the function pointer issue where print_generic_decl() also rather repeats the declaration instead of printing the new type. Thanks.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #9 from rguenther at suse dot de rguenther at suse dot de 2011-02-09 16:33:30 UTC --- On Wed, 9 Feb 2011, joe at mcknight dot de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #8 from joe at mcknight dot de 2011-02-09 16:23:44 UTC --- (In reply to comment #6) See http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00956.html for a patch (queued for 4.7, several tree-dump check testcases have to be adjusted). Richard, I've found another example for incorrect output of print_generic_decl(). Here: typedef struct { double dvar; int ivar; } *tpdefp; int myfunc(tpdefp var); The output would not treat the variable as being of the new type but it would repeat the declaration of the struct in print_generic_decl() and output (including newlines): extern int myfunc (struct { double dvar; int ivar; } *); That could be related to the function pointer issue where print_generic_decl() also rather repeats the declaration instead of printing the new type. You should use a debugger to see why that happens, it should end up printing TYPE_NAME which should be a TYPE_DECL with a DECL_NAME which should be an IDENTIFIER_NODE. You can also try TDF_SLIM. Richard.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #10 from joe at mcknight dot de 2011-02-09 18:08:32 UTC --- Created attachment 23285 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23285 A small test plugin that calls print_generic_decl()
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #11 from joe at mcknight dot de 2011-02-09 18:11:10 UTC --- Created attachment 23286 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23286 A C file that provokes wrong output of print_generic_decl()
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #12 from joe at mcknight dot de 2011-02-09 18:14:36 UTC --- That could be related to the function pointer issue where print_generic_decl() also rather repeats the declaration instead of printing the new type. You should use a debugger to see why that happens, it should end up printing TYPE_NAME which should be a TYPE_DECL with a DECL_NAME which should be an IDENTIFIER_NODE. You can also try TDF_SLIM. Unfortunately I'm not too experienced with debugging gcc... I tried TDF_SLIM but this makes things rather worse than better. Instead I have added a small testcase, a basic plugin that outputs a function declaration and a small .c file containing functions that are incorrectly output by the plugin. I hope this is of help for someone more knowledgeable in debugging gcc than me. If I can provide any further help, please let me know. Thanks.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-02-08 19:13:07 UTC --- print_generic_decl is designed for debugging reasons only. Any other use is a bit bogus. Also asking for help with plugins is not really a bug report but should goto the gcc@ list.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #3 from joe at mcknight dot de 2011-02-08 20:08:51 UTC --- (In reply to comment #2) print_generic_decl is designed for debugging reasons only. Any other use is a bit bogus. Also asking for help with plugins is not really a bug report but should goto the gcc@ list. I am reporting the bug that print_generic_decl() is behaving incorrectly for some kinds of declarations. This should either be fixed or a comment be placed in the source code that warns about the usage of this function (and ideally propose a better one).
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-02-08 20:10:43 UTC --- (In reply to comment #3) I am reporting the bug that print_generic_decl() is behaving incorrectly for some kinds of declarations. This should either be fixed or a comment be placed in the source code that warns about the usage of this function (and ideally propose a better one). Well I think you need to debug it to see why it is printing out static, it might because a bit on tree has not been set yet.
[Bug middle-end/47650] wrong output of print_generic_decl() called from a plugin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47650 --- Comment #5 from joe at mcknight dot de 2011-02-08 20:16:28 UTC --- (In reply to comment #4) Well I think you need to debug it to see why it is printing out static, it might because a bit on tree has not been set yet. The static is a very minor issue. What is worse is that it doesn't see the ellipsis and turns void barfunc (int foo, int abc, ... ) into void barfunc (int). It also outputs incorrect C when dealing with function pointers.