This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [GOOGLE] More strict checking for call args


On Wed, Jun 5, 2013 at 2:19 AM, Dehao Chen <dehao@google.com> wrote:
> attached is a testcase that would cause problem when source has changed:
>
> $ g++ test.cc -O2 -fprofile-generate -DOLD
> $ ./a.out
> $ g++ test.cc -O2 -fprofile-use
> test.cc:34:1: internal compiler error: in operator[], at vec.h:815
>  }
>  ^
> 0x512740 vec<tree_node*, va_heap, vl_embed>::operator[](unsigned int)
> ../../gcc/vec.h:815
> 0x512740 vec<tree_node*, va_heap, vl_ptr>::operator[](unsigned int)
> ../../gcc/vec.h:1244
> 0xf24464 vec<tree_node*, va_heap, vl_embed>::operator[](unsigned int)
> ../../gcc/vec.h:815
> 0xf24464 vec<tree_node*, va_heap, vl_ptr>::operator[](unsigned int)
> ../../gcc/vec.h:1244
> 0xf24464 ipa_get_indirect_edge_target_1
> ../../gcc/ipa-cp.c:1535

This use needs to be properly guarded.  We can perfectly well have
mismatching fndecl nodes in gimple calls.  If we start with

void fn(int, int, int);

...
void (*x)(float, double, struct X, int) = fn;
(*x)(1., 2., {}, 1);

the GIMPLE_CALL receives the function type effective for the call
from the source (gimple_call_fntype).  Then CCP happily propagates the
'fn' decl and we end up with

  fn (1., 2., {}, 1);

that is, gimple_call_fndecl is 'fn' but gimple_call_fntype is still
void (*x)(float, double, struct X, int)!

So the solution is not to fix the argument verification predicate but to make
code aware of the fact that for the call statement gimple_call_fntype is
relevant for what is a valid call (that's also what is verified against in
verify_stmts) even though the ultimate called function-decl 'fn' has a
different prototype.  Thus any code propagating from a call site to
the callee has to deal with mismatches.

Richard.

> 0x971b9a estimate_edge_devirt_benefit
> ../../gcc/ipa-inline-analysis.c:2757
> 0x973f59 estimate_edge_size_and_time
> ../../gcc/ipa-inline-analysis.c:2789
> 0x973f59 estimate_calls_size_and_time
> ../../gcc/ipa-inline-analysis.c:2842
> 0x97429f estimate_node_size_and_time
> ../../gcc/ipa-inline-analysis.c:2929
> 0x976077 do_estimate_edge_size(cgraph_edge*)
> ../../gcc/ipa-inline-analysis.c:3472
> 0x97614f estimate_edge_size
> ../../gcc/ipa-inline.h:274
> 0x97614f estimate_edge_growth
> ../../gcc/ipa-inline.h:286
> 0x97614f do_estimate_growth_1
> ../../gcc/ipa-inline-analysis.c:3582
> 0x7e41df cgraph_for_node_and_aliases
> ../../gcc/cgraph.c:1777
> 0x976675 do_estimate_growth(cgraph_node*)
> ../../gcc/ipa-inline-analysis.c:3596
> 0xf314ea estimate_growth
> ../../gcc/ipa-inline.h:261
> 0xf314ea inline_small_functions
> ../../gcc/ipa-inline.c:1432
> 0xf314ea ipa_inline
> ../../gcc/ipa-inline.c:1797
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://gcc.gnu.org/bugs.html> for instructions.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]