search for: actualcallees

I actually need this feature quite badly in my untyped language compiler: since I support first-class functions, I've made the types of all functions a standard vararg (so I can box them). The implementation crashes when I try to read out the value of gc.result. Hints as to what might be wrong? Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> ---

...correctly, it only tries to resolve indirect calls. The > analysis doesn't track direct calls because you can do it just as well > yourself. DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to iterate over an empty set (EmptyActual) for any call site not found in the ActualCallees map. So if direct calls are not tracked, then I would expect the callee iterators for *both* direct calls to yield this empty set. Getting the empty set for one direct call but a correct singleton set for the other direct call is a troubling inconsistency that leaves me unsure which results I can...

...o resolve indirect calls.  The >> analysis doesn't track direct calls because you can do it just as well >> yourself. > > DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to > iterate over an empty set (EmptyActual) for any call site not found in > the ActualCallees map.  So if direct calls are not tracked, then I would > expect the callee iterators for *both* direct calls to yield this empty > set.  Getting the empty set for one direct call but a correct singleton > set for the other direct call is a troubling inconsistency that leaves > me unsure...

On Tue, Aug 9, 2011 at 6:19 PM, Ben Liblit <liblit at cs.wisc.edu> wrote: > I am using EQTDDataStructures (from the poolalloc project) to resolve > indirect function calls to over-approximated sets of possible callees. If I remember correctly, it only tries to resolve indirect calls. The analysis doesn't track direct calls because you can do it just as well yourself. Andrew

I am using EQTDDataStructures (from the poolalloc project) to resolve indirect function calls to over-approximated sets of possible callees. Unfortunately I find that it yields incorrect results even on a very simple test input. My LLVM and poolalloc sources are Subversion trunk checkouts, no more than a day older than the current trunk head. My test input is the following C source,

...?The >>> analysis doesn't track direct calls because you can do it just as well >>> yourself. >> >> DSCallGraph::callee_begin() and DSCallGraph::callee_end() cooperate to >> iterate over an empty set (EmptyActual) for any call site not found in >> the ActualCallees map. ?So if direct calls are not tracked, then I would >> expect the callee iterators for *both* direct calls to yield this empty >> set. ?Getting the empty set for one direct call but a correct singleton >> set for the other direct call is a troubling inconsistency that leaves &g...