Re: [PATCH] Forward VALUE_LVAL when avoiding side effects for STRUCTOP_STRUCT

[Joel Brobecker <brobecker at adacore dot com>]

> Ignoring that we have a not_lval operand for UNOP_ADDR in this mode affects
> type resolution. In particular, I observed the following regression (from
> gdb.base/ptype.exp):
> 
>     (gdb) ptype *&{4,5,6}[1]
>     type = int
>     # The testsuite expects:
>     #   Attempt to take address of value not located in memory.
> 
> My previous attempt in the case STRUCTOP_STRUCT preserves this (important)
> information in EVAL_AVOID_SIDE_EFFECTS mode so we do not have this kind of
> regression.

It took me a while to accept that, yes, we are losing critical
info and that the value's lval kind provides it.

> I donât really understand why fake values must be not_lval: is this
> documented somewhere? After all, code is not supposed to use the content of
> fake values (but only their types and other similar attributes), right?
> Besides not all not_lval are fake values.

I thought it was safer to just mark fake values as not_val so
as to avoid accidentally using them as if they were real values.
But I see now that there are numerous examples of value_zero being
called with something other than not_lval, and a few in particular
that "propagate" the lval the way you do during EVAL_AVOID_SIDE_EFFECT,
presumably for the same reason.

Patch is OK with the change I mentioned in the first review.

> Beyond this, I have no idea about how to cleanly fix the original bug.
> 
> >>+# Sanity checking:
> >>+gdb_test "print &foo_array\[1\].a" "= \\(int \\*\\) 0x.*"
> >
> >Use "$hex.*" instead of "0x.*"...
> 
> Fixed.

-- 
Joel