Re: Code in can_use_hardware_watchpoint()

[jtc@redback.com (J.T. Conklin)]

>>>>> "Michael" == Michael Snyder <msnyder@cygnus.com> writes:
>> But I'm wondering if instead the v->modifiable == 0 should be == 1
>> instead.

Michael> Could you elaborate on that thought?  I'm not sure I
Michael> understand why the function should give a negative return if
Michael> a subexpression is not_lval and !modifiable.  Is it trying to
Michael> detect constants?  Or what?

I not sure what 'v->lval != not_lval && v->modifiable == 0' is trying
to catch.  I put a breakpoint at can_use_hardware_watchpoint(), tried
every sort of watch expression I could expect, and only found nodes
with v->lval == lval_memory, v->lval == lval_register, and v->lval ==
not_lval && v->modifiable == 0.  Because I didn't see anything that
tripped that expression, I thought that it might contain a bug.  If
not, it's in desparate need of a comment...

When I suggested changing the expression to 'v->lval != not_lval &&
v->modifiable == 1', I was thinking that anything that's modifiable
that isn't in memory should be rejected.

I thought that a catch all expression might be better in case new
value types are added.  In fact, it looks like lval_reg_frame_relative
types should be rejected one way or the other now.

        --jtc

-- 
J.T. Conklin
RedBack Networks