Fixed bug in CFG::PopulateBlkExprMap where the ordering

between fetching the size of the expression map (for use as
the next integer id for an Expr*) and the creation of the
entry in the map could be non-deterministic.  This could
cause the size of the map to be incremented prior to the
index being determine.

On Linux the map entry would be created first, causing the
map to the "size" to be incremented prior to it being
queried. On Mac OS X we had the reverse behavior. Now the
size is always queried prior to the new id being inserted
into the map.

This was the real cause of the bit-overrun triggered in
PR 1847:

  http://llvm.org/bugs/show_bug.cgi?id=1847
  
Also reverted the change in patch 44813, which was a bogus
fix to this problem:

  http://llvm.org/viewvc/llvm-project?rev=44813&view=rev

llvm-svn: 44822
This commit is contained in:
Ted Kremenek 2007-12-10 23:58:39 +00:00
parent f182e81d85
commit c0870605be
2 changed files with 6 additions and 4 deletions

View File

@ -969,8 +969,10 @@ static BlkExprMapTy* PopulateBlkExprMap(CFG& cfg) {
for (CFG::iterator I=cfg.begin(), E=cfg.end(); I != E; ++I)
for (CFGBlock::iterator BI=I->begin(), EI=I->end(); BI != EI; ++BI)
if (const Expr* E = dyn_cast<Expr>(*BI))
(*M)[E] = M->size();
if (const Expr* E = dyn_cast<Expr>(*BI)) {
unsigned x = M->size();
(*M)[E] = x;
}
return M;
}

View File

@ -73,7 +73,7 @@ struct DeclBitVector_Types {
public:
void resetValues(AnalysisDataTy& AD) {
DeclBV.resize(AD.getNumDecls()+1);
DeclBV.resize(AD.getNumDecls());
DeclBV.reset();
}
@ -172,7 +172,7 @@ struct ExprDeclBitVector_Types {
void resetValues(AnalysisDataTy& AD) {
ParentRef(*this).resetValues(AD);
ExprBV.resize(AD.getNumExprs()+1);
ExprBV.resize(AD.getNumExprs());
ExprBV.reset();
}