[Bug tree-optimization/46507] std::get and devirtualization on non-automatic variables

["rguenther at suse dot de" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507

--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 16 Jan 2014, hubicka at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46507
> 
> --- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---

void arg_tuple_test(const std::pair<A, A>&) (const struct pair & t)
{
  int (*__vtbl_ptr_type) () * _3;
  int (*__vtbl_ptr_type) () _4;
  const struct A & _6;

  <bb 2>:
  _6 = &t_1(D)->first;
  _3 = MEM[(const struct type *)t_1(D)]._vptr.A;
  _4 = *_3;
  OBJ_TYPE_REF(_4;(const struct A)_6->0) (_6); [tail call]
  return;

}
Here we look all the way to figuring out that the object comes as 
parameter
of
arg_tuple_test and give up on this point.
I think GIMPLE typing rules does not really allow us to take the type from
COMPONENT_REF in statement defining _6, so it seems we completely lose 
track
of
the type info here. (and it indeed looks like a common case)

Richard?

That is correct.  &t_1(D)->first is merely pointer offsetting and
we may not forward it to form t_1(D)->first._vptr.A for example
(there were wrong-code bugs because of such forwarding in the past).

In GIMPLE you don't have type information on pointed to types, you only
have type info for values.

> Hmm, also if there is anything in standard that prevents user to pass 
> object of type A by reference to type B (where A is not derived from B) 
> then we can get the type info from type of parameter t.

"Standards" do not apply to GIMPLE so you have to be very careful
in this area (one reason why I am not exactly comfortable about
all this devirt and ODR stuff done in the middle-end as opposed
to in a frontend).

Richard.