> Hi, > > On Mon, Feb 17, 2014 at 09:40:40AM +0100, Jan Hubicka wrote: > > Hi, > > Chromium LTO build ICEs on bogus get_binfo_at_offset call. This is caused by > > updating pasto bug in update_jump_functions_after_inlining. > > > > While looking for it I noticed we have other issues here. In particular, > > when > > combining -fno-devirtualize and -fdevirtualize units, we get all jump > > fuctions > > as type preserved. This is because detect_type_change returns false when it > > decides detection is not needed. It really should return true. Otherwise we > > will > > end up propagating invalid types through the -fno-devirtualize function and > > produce > > wrong code at LTO. > > > > I also added some sanity checking to jump functions while hunting the bug > > that > > uncovered another problem in compute_complex_assign_jump_func and > > compute_complex_ancestor_jump_func that are still confusing type of > > parameter > > (that is pointer) to type of object passed by reference. > > > > I also made us to not save the type to ipa_set_ancestor_jf when type is not > > preserved, since it will never be used for enything useful. > > ipa_get_jf_ancestor_result > > uses to build it the updated address, but we can safely use > > pointer_type_node, > > because it will be converted at the substitution time anyway. > > > > Bootstrapped/regtested x86_64-linux, will commit it tomorrow after some > > furhter testing > > and unless Martin stops me ;) > > > > Honza > > > > * ipa-cp.c (ipa_get_jf_ancestor_result): Allow type to be NULL. > > * ipa-prop.c (ipa_set_jf_known_type): Do not set anyting when > > we do not devirtualize. > > (ipa_set_ancestor_jf): Likewise; do not record type when we do not > > devirtualize. > > (detect_type_change): Signalize type change when giving up on > > detection. > > (compute_complex_assign_jump_func): Fix call of ipa_set_ancestor_jf. > > (compute_complex_ancestor_jump_func): Likewise. > > (update_jump_functions_after_inlining): Fix combining of PASS_THROUGH > > and KNOWN_TYPE. > > This is fine, except that if we allow having NULL as the type of > ancestor jump functions, this should be stated and explained in a > comment in ipa_ancestor_jf_data in ipa-prop.h.
I will update the comment prior comitting, thanks! Basically we want to be cureful about what information we store, since it all has to go cross the pipes to linktime compilation stage. Honza > > Thanks, > > Martin
