struct A { void operator= (A &); A (); }; struct B { A b; }; struct C { virtual bool foo (int &, bool) const; }; struct D : virtual C { bool foo (int &, bool) const; B e; }; struct F : D { F (int &, const int &, const A &); bool foo (int &, bool) const; }; bool D::foo (int &, bool) const {} F::F (int &, const int &, const A &) {} bool F::foo (int &, bool) const {} ICEs on armv7hl-linux-gnuaebi, with -O2 -fpic. I believe the bug has been introduced with r211045, but haven't verified it.
snode = symtab_node::get (decl); if (snode->alias) { rtx target = DECL_RTL (snode->ultimate_alias_target ()->decl); place_block_symbol (target); SYMBOL_REF_BLOCK_OFFSET (symbol) = SYMBOL_REF_BLOCK_OFFSET (target); return; } is of course bogus, DECL_RTL is very unlikely a SYMBOL_REF, it should be a MEM with SYMBOL_REF as operand. The question is if we can assert that. If that wouldn't be the case, I guess the optimizers would need to prevent creation of the alias.
Created attachment 34713 [details] gcc5-pr65003.patch Untested fix. If the assert ever triggers, I guess we'll need to do something smarter in the cgraph area. Note that symbols that are aliases from the beginning aren't a problem here, the only problem is if a symbol has RTL created too early (in this case because of notice_global_symbol) and then IPA or whatever turns it into an alias to some other symbol.
Author: jakub Date: Wed Feb 11 15:09:48 2015 New Revision: 220625 URL: https://gcc.gnu.org/viewcvs?rev=220625&root=gcc&view=rev Log: PR middle-end/65003 * varasm.c (place_block_symbol): Assert that DECL_RTL of the ultimate alias is MEM with SYMBOL_REF satisfying SYMBOL_REF_HAS_BLOCK_INFO_P as its operand. Don't pass the MEM to place_block_symbol, but instead pass the SYMBOL_REF operand of it. * g++.dg/opt/pr65003.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr65003.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/varasm.c
Fixed.
*** Bug 65036 has been marked as a duplicate of this bug. ***
*** Bug 65035 has been marked as a duplicate of this bug. ***
*** Bug 65030 has been marked as a duplicate of this bug. ***
*** Bug 65031 has been marked as a duplicate of this bug. ***