https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562
--- Comment #6 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 28 Nov 2016, gjl at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78562 > > --- Comment #5 from Georg-Johann Lay <gjl at gcc dot gnu.org> --- > Maybe it is an option to be less strict? In the test case, both function name > and asm name (libname) are in the namespace of the implementation: both start > with 2 underscores. The function name even starts with __builtin_... Yes, as I said, being less strict and for example not diagnosing this as if it were in "system headers" would probably work. diff --git a/gcc/lto/lto-symtab.c b/gcc/lto/lto-symtab.c index ce9e146..cf53d62 100644 --- a/gcc/lto/lto-symtab.c +++ b/gcc/lto/lto-symtab.c @@ -655,6 +655,13 @@ lto_symtab_merge_decls_2 (symtab_node *first, bool diagnosed_p) /* Diagnose all mismatched re-declarations. */ FOR_EACH_VEC_ELT (mismatches, i, decl) { + /* Do not diagnose two built in declarations, there is no useful + location in that case. It also happens spuriously for AVR, + see PR78562. */ + if (DECL_IS_BUILTIN (prevailing->decl) + && DECL_IS_BUILTIN (decl)) + continue; + int level = warn_type_compatibility_p (TREE_TYPE (prevailing->decl), TREE_TYPE (decl), DECL_COMDAT (decl)); works for me for the testcase. Can you give it some more testing on your side and propose it on the mailing list?
