Re: [patch 11/12] entryval#2: @entry values even for references

[Pedro Alves <pedro@codesourcery.com>]

On Friday 23 September 2011 12:39:41, Jan Kratochvil wrote:
> On Fri, 23 Sep 2011 11:50:22 +0200, Pedro Alves wrote:
> > Sorry, in the hurry, I hadn't noticed you had used `S &s; class S { char a, b; };'.
> > That's not the case I raised originally.  The case is an entry val of
> > type `struct { int a; long &b; }'.  Calling an entry object of that
> > type `s', if we "print s@entry", I think we'll:
> 
> In such case the parameter `s' is not TYPE_CODE_REF and therefore
> entry_data_value_funcs do not get ever used and therefore
> coerce_ref_if_computed will always return NULL.
> 
> coerce_ref_if_computed is there only as a hack for TYPE_CODE_REF which
> dereferences into something else than what a native normal such
> TYPE_CODE_REF-pointer would derefefence into.

I see, thanks.  Okay, let's go with this, with the
embedded_offset == 0 assertion in place.

I really dislike lval_computed special casing.  We should be
aiming at making it generic enough to be able to reimplement the
regular lval_memory/lval_register, etc. lval types as lval_computed,
hence my insistence.

-- 
Pedro Alves