On Thu, Dec 1, 2016 at 11:07 AM, Prathamesh Kulkarni <prathamesh.kulka...@linaro.org> wrote: > Hi, > As mentioned in PR, the issue seems to be that in > propagate_bits_accross_jump_functions(), > ipa_get_type() returns record_type during WPA and hence we pass > invalid precision to > ipcp_bits_lattice::meet_with (value, mask, precision) which eventually > leads to runtime error. > The attached patch tries to fix that, by bailing out if type of param > is not integral or pointer type. > This happens for the edge from deque_test -> _Z4copyIPd1BEvT_S2_T0_.isra.0/9.
Feels more like a DECL_BY_REFERENCE mishandling and should be fixed elsewhere. > However I am not sure how ipcp_bits_lattice::meet_with (value, mask, > precision) gets called for this case. In > ipa_compute_jump_functions_for_edge(), we set jfunc->bits.known to > true only > if parm's type satisfies INTEGRAL_TYPE_P or POINTER_TYPE_P. > And ipcp_bits_lattice::meet_with (value, mask, precision) is called > only if jfunc->bits.known > is set to true. So I suppose it shouldn't really happen that > ipcp_bits_lattice::meet_with(value, mask, precision) gets called when > callee parameter's type is record_type, since the corresponding > argument's type would also need to be record_type and > jfunc->bits.known would be set to false. > > Without -flto, parm_type is reference_type so that satisfies POINTER_TYPE_P, > but with -flto it's appearing to be record_type. Is this possibly the > same issue of TYPE_ARG_TYPES returning bogus types during WPA ? > > I verified the attached patch fixes the runtime error with ubsan-built gcc. > Bootstrap+tested on x86_64-unknown-linux-gnu. > Cross-tested on arm*-*-*, aarch64*-*-*. > LTO bootstrap on x86_64-unknown-linux-gnu in progress. > Is it OK to commit if it succeeds ? > > Thanks, > Prathamesh
