[cfe-commits] [PATCH] RegionStore

Zhongxing Xu xuzhongxing at gmail.com
Sun Oct 19 22:05:16 PDT 2008


On Mon, Oct 20, 2008 at 12:51 PM, Zhongxing Xu <xuzhongxing at gmail.com>wrote:

>
>
> On Mon, Oct 20, 2008 at 12:48 PM, Zhongxing Xu <xuzhongxing at gmail.com>wrote:
>
>>
>>
>> On Mon, Oct 20, 2008 at 12:28 PM, Ted Kremenek <kremenek at apple.com>wrote:
>>
>>>
>>> On Oct 19, 2008, at 6:24 AM, Zhongxing Xu wrote:
>>>
>>>  1. Initial support for local arrays in RegionStoreManager::AddDecl()
>>>> 2. Move special processing of loading array variable's lvalue from
>>>> GRExprEngine to Store. This simplifies code. And this is also what we have
>>>> to do when we processing code like:
>>>>
>>>
>>> Hi Zhongxing,
>>>
>>> The following down cast is not necessary, as R is a VarRegion:
>>
>>
>> Fixed.
>>
>>
>>>
>>>
>>> +++ lib/Analysis/BasicStore.cpp (工作副本)
>>> @@ -42,7 +42,6 @@
>>>
>>>   virtual MemRegionManager& getRegionManager() { return MRMgr; }
>>>
>>> -  // FIXME: Investigate what is using this. This method should be
>>> removed.
>>>   virtual Loc getLoc(const VarDecl* VD) {
>>>     return loc::MemRegionVal(MRMgr.getVarRegion(VD));
>>>   }
>>> @@ -148,7 +147,15 @@
>>>
>>>       if (!R)
>>>         return UnknownVal();
>>> -
>>> +
>>> +      // We let an array variable's rvalue be its lvalue, because we
>>> have to
>>> +      // process code like: int a[10]; int (*p)[10]; p = &a; (*p)[3] =
>>> 1; The
>>> +      // other benifit is that we can save the special handling of array
>>> +      // variables in VisitDeclRefExpr().
>>> +      if (const VarRegion* VR = dyn_cast<VarRegion>(R))
>>> +        if (VR->getDecl()->getType()->isArrayType())
>>> +          return LV;
>>> +
>>>
>>> I'm also not certain why this logic is needed (or if it is correct).  The
>>> expression '&a' is handled by VisitUnaryOperator, and for the case of '&' it
>>> calls VisitLValue on its subexpression.  I don't see where a call to GetSVal
>>> is involved.
>>>
>>> The cleanups to GRExprEngine are very nice.
>>>
>>> All in all the patch looks good, but I am a little unclear about why
>>> BasicStore::GetSVal should return the lvalue for an array in an rvalue
>>> context.  GRExprEngine handles the implicit conversions between lvalues and
>>> rvalues, not the store.
>>>
>>> When we visit (*p)[3] = 1, we evaluate (*p)'s rvalue. We will do a load
>> on p's rvalue, which is loc::MemRegionVal(region of a). We want (*p)'s
>> rvalue still be loc::MemRegionVal(region of a). So we should handle this in
>> Store.
>>
>
> It's actually a special "load" not going through the binding.
>

As a more direct example, consider code

int a[10];
a[1] = 3;

When we visit a[1], we evaluate a's rvalue. In VisitDeclRefExpr, we first
get a's lvalue loc::MemRegionVal(a's region), then do a load on it. We
expect to load loc::MemRegionVal(a's region) from itself. Then a
ImplicitCast will convert it to a pointer to a's first element.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20081020/1fa07739/attachment.html>


More information about the cfe-commits mailing list