On November 23, 2015 5:50:25 PM GMT+01:00, Jan Hubicka <hubi...@ucw.cz> wrote: >> >> I think it also causes the following and one related ICE >> >> FAIL: gcc.dg/vect/pr62021.c -flto -ffat-lto-objects (internal >compiler >> error) >> >> >/space/rguenther/src/svn/trunk3/gcc/testsuite/gcc.dg/vect/pr62021.c:7:1: > >> internal compiler error: in get_alias_set, at alias.c:880^M >> 0x7528a7 get_alias_set(tree_node*)^M >> /space/rguenther/src/svn/trunk3/gcc/alias.c:880^M > >Does this one reproduce with mainline?
Yes, testsuite run on x86_64 All thee ICEs are on the sanity >check: >gcc_checking_assert (!in_lto_p || !type_with_alias_set_p (t)); >which check that in LTO all types that ought to have CANONICAL_TYPE >gets CANONICAL_TYPE >computed. ICE here probalby means that the type somehow bypassed LTO >canonical type merging >as well as the TYPE_CANONICAL=MAIN_VARIANT set in lto-streamer.c > >Honza
