http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- "jakub at gcc dot gnu.org" <gcc-bugzi...@gcc.gnu.org> wrote: >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59470 > >--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- >CXXFLAGS='-fstack-protector ...' ../configure ... >(at least I believe so, we override a bunch of other variables in the >gcc.spec >file). > >Anyway, I've instrumented gcc so that based on env var it used the >r205708 way >of TER for some functions and r205709 for others and it seems for this >testcase >the only problematic one is >_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE13_M_insert_intIlEES3_S3_RSt8ios_basecT_ > >On that function, I see that the r205709 change made _46, _47, _114, >_119 and >_126 not TERable. >That's: >_46 = MEM[(const struct __cache_type *)prephitmp_130]._M_grouping_size; > _47 = MEM[(const struct __cache_type *)prephitmp_130]._M_grouping; >std::num_put<char>::_M_group_int (this_48(D), _47, _46, _45, >__io_10(D), >__cs_43, __cs_36, &__len); >... > _114 = MEM[(const struct locale &)__io_10(D) + 108]._M_impl; > std::locale::_Impl::_M_install_cache (_114, __tmp_113, __i_107); >... > _119 = MEM[(int (*__vtbl_ptr_type) () *)_118 + 4B]; > OBJ_TYPE_REF(_119;__tmp_113->1) (__tmp_113); >... > _126 = MEM[(int (*__vtbl_ptr_type) () *)_125 + 48B]; >_127 = OBJ_TYPE_REF(_126;__s$_M_sbuf_106->12) (__s$_M_sbuf_106, __cs_3, >prephitmp_175); > >All of these single use SSA_NAMEs. I don't see why these shouldn't be >TERable, >function arguments necessarily are evaluated before the function is >called and >the aliasing stmt_may_clobber_ref_p talks about are either the >side-effects of >the call itself, or storing to the lhs. >So, for calls, can't we do only the first part of >stmt_may_clobber_ref_p_1 >handling and not the rest (i.e. the gimple_call_lhs handling there >only), >unless the SSA_NAME is used somewhere in the lhs of the call? No, it's exactly the side.effect that matters here. The call invalidates the address of the memory we store the call result to. We can probably restrict this to calls with non.register lhs and asm statements with memory outputs though. Of course that complicates the patch. Richard. >Similarly for ASMs, IMHO terring into inline asm is especially >important, while >your change pretty much disables it always: > else if (gimple_code (stmt) == GIMPLE_ASM) > return true; >What should be avoided is if SSA_NAME is used in some output operand >(say as >part of a reference), that I can understand why we shouldn't ter. But >otherwise? > >Note, this of course doesn't explain why this PR breaks.
