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? :-)...)