Created attachment 31156 [details] first source User defined built-in implementation cause lto error. Use source files in the attachment, following commands can reproduce this problem. xxx-gcc *.c -O2 -flto -c xxx-gcc *.o -o tt.mid -r -O2 -flto -nostdlib lto1: error: two or more sections for .gnu.lto_scalbnf.a2a70fd51cfc1298 (null):0: confused by earlier errors, bailing out lto-wrapper: ../powerpc-unknown-linux-gnu-gcc returned 1 exit status collect2: error: lto-wrapper returned 1 exit status ======================================================== It seems that there is a bug in lto_symtab_merge_cgraph_nodes_1 in lto-symtab.c. cgraph_node *ce = dyn_cast <cgraph_node> (e); if (ce && !DECL_BUILT_IN (e->symbol.decl)) lto_cgraph_replace_node (ce, cgraph (prevailing)); if (varpool_node *ve = dyn_cast <varpool_node> (e)) lto_varpool_replace_node (ve, varpool (prevailing)); The function will do real replace only when e is NOT referring to a built-in function.This is not right, because user can provide their own built-in implementations which should also be merged. we change DECL_BUILT_IN (e->symbol.decl)) to DECL_IS_BUILTIN (e->symbol.decl)) to fix this problem, is the fix ok for the mainstream?
Created attachment 31157 [details] second source
This works on trunk, but of course symtab merging is pre-empted here by tree merging I think. The error can be reproduced on trunk with t1.i ---- __attribute__((weak)) float scalbnf(float z) { return z; } t2.i ---- __attribute__((weak)) float scalbnf(float x, int y) { return x*y; } which would be kind of invalid, of course. Or with t1.i ---- __attribute__((weak,used)) float scalbnf(float x, int y) { return x*y; } t2.i ---- __attribute__((weak)) float scalbnf(float x, int y) { return x*y; } or with any other unrelated and harmless extra attribute on one decl. This never worked btw.
(In reply to Richard Biener from comment #2) > This works on trunk, but of course symtab merging is pre-empted here by tree > merging I think. The error can be reproduced on trunk with t1.i ---- > __attribute__((weak)) float scalbnf(float z) { return z; } t2.i ---- > __attribute__((weak)) float scalbnf(float x, int y) { return x*y; } > which would be kind of invalid, of course. Or with t1.i ---- > __attribute__((weak,used)) float scalbnf(float x, int y) { return x*y; } > t2.i ---- __attribute__((weak)) float scalbnf(float x, int y) { return > x*y; } or with any other unrelated and harmless extra attribute on one > decl. This never worked btw. Thanks for the reply.Yes, the problem can be reproduced by any built-in functions when there are two global definitions(of cources,with the same name) in the lto linking process. The tree merging decided to merge the two definitions as there can only be one global definition in a object file.This is right ,but the lto_symtab_merge_cgraph_nodes_1 refuse to do the real merge. Built-in functions which are NOT defined by user have no real bodys in the object file, so they does not need a real merge.I think that is what lto_symtab_merge_cgraph_nodes_1 really want to do.Unfortunately,It make a mistake by using DECL_BUILT_IN rather than DECL_IS_BUILTIN.
*** Bug 52159 has been marked as a duplicate of this bug. ***
Found my way here via bug #52159. When building Qemu with -flto I get with gcc-5.3.0: [...] lto1: error: two or more sections for .gnu.lto_fprintf.288635079aa9eb60 (null):0: confused by earlier errors, bailing out lto-wrapper: fatal error: /usr/x86_64-pc-linux-gnu/gcc-bin/5.3.0/x86_64-pc-linux-gnu-g++ returned 1 exit status compilation terminated. /usr/lib/gcc/x86_64-pc-linux-gnu/5.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: error: ld returned 1 exit status
Same problem as above when compiling qemu with lto with GCC-5.4.0.
(In reply to Richard Biener from comment #2) > This works on trunk, but of course symtab merging is pre-empted here by > tree merging I think. The error can be reproduced on trunk with > > t1.i > ---- > __attribute__((weak)) float > scalbnf(float z) { return z; } > > t2.i > ---- > __attribute__((weak)) float > scalbnf(float x, int y) { return x*y; } > > which would be kind of invalid, of course. "kind of" invalid?