This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug ipa/65298] [5 Regression] lto1: ICE: in operator[], at vec.h:736 during LTO/PGO Firefox build
- From: "hubicka at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 03 Mar 2015 17:49:57 +0000
- Subject: [Bug ipa/65298] [5 Regression] lto1: ICE: in operator[], at vec.h:736 during LTO/PGO Firefox build
- Auto-submitted: auto-generated
- References: <bug-65298-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65298
--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
lto1: internal compiler error: in operator[], at vec.h:736
0xffc277 vec<tree_node*, va_heap, vl_embed>::operator[](unsigned int)
../../gcc/gcc/vec.h:736
0xffd678 vec<tree_node*, va_heap, vl_embed>::operator[](unsigned int)
../../gcc/gcc/vec.h:1184
0xffd678 vec<tree_node*, va_heap, vl_ptr>::operator[](unsigned int)
../../gcc/gcc/vec.h:1202
0xffd678 ipa_value_from_jfunc(ipa_node_params*, ipa_jump_func*)
../../gcc/gcc/ipa-cp.c:937
The out of range access here is caused by pass through function specifying an
index of function parameter that is past the end of ipa-cp lattice.
I suppose it is either some kind of datastructure corruption or a fact that we
manage to inline function call with mismatching arguments?
I saw ICE on this spot in the past and they usually were the first - we forgot
to update correctly after inlining...
What is your -march=native?