Displaying 5 results from an estimated 5 matches for "bottomupclosure".
2004 Sep 02
0
[LLVMdev] Problem with CVS LLVM build in obj != src dir case
...pkg/build/llvm/src/llvm/utils/TableGen/TableGen.cpp:234:
warning: converting of negative value `-0x000000001' to `unsigned int'
/home/wanderer/pkg/build/llvm/src/llvm/utils/TableGen/TableGen.cpp:235:
warning: converting of negative value `-0x000000001' to `unsigned int'
Compiling BottomUpClosure.cpp
/home/wanderer/pkg/build/llvm/src/llvm/lib/Analysis/DataStructure/BottomUpClosure.cpp:
In member function `unsigned int
llvm::BUDataStructures::calculateGraphs(llvm::Function*,
std::vector<llvm::Function*, std::allocator<llvm::Function*> >&, unsigned
int&, __gnu_cxx::has...
2004 Sep 01
2
[LLVMdev] Problem with CVS LLVM build in obj != src dir case
LLVM build without big problems in obj dir == src dir case (for example,
last night tester build)
But I have problem with building CVS version LLVM in obj dir != src dir
case.
======= Finished building ModuleMaker debug executable (without symbols)
=======
gmake[2]: Leaving directory
`/usr/home/wanderer/pkg/build/llvm/obj/examples/ModuleMaker'
gmake[1]: Leaving directory
2004 Sep 02
1
[LLVMdev] Problem with CVS LLVM build in obj != src dir case
...GCC 3.5 (yet). I personally won't use it until 3.5.1 is available as
I don't like to waste my time with compiler flaws. So, if you'd like to
get rid of these warnings, the simplest solution is to use GCC 3.4.
Otherwise, you'll need to fix them yourself.
Reid.
>
> Compiling BottomUpClosure.cpp
> /home/wanderer/pkg/build/llvm/src/llvm/lib/Analysis/DataStructure/BottomUpClosure.cpp:
> In member function `unsigned int
> llvm::BUDataStructures::calculateGraphs(llvm::Function*,
> std::vector<llvm::Function*, std::allocator<llvm::Function*> >&, unsigned
>...
2013 Mar 04
2
[LLVMdev] Unexpected DSAnalysis behavior
...contain any hint on the read of the global variable ARR. These
graphs thus do not reflect the full effects of the methods, which I expected them to do. (Screenshots attached)
This seems to be deliberate as the code states that "[...] we don't care about merging globals [...] here"
(BottomUpClosure.cpp:641 in the release_32 version from the poolalloc SVN).
The "here" in the comment suggests that this should happen at some later point, which it doesn't.
This behavior is also not in line with the PLDI Paper.
Is it intended? And if so, why?
Thanks for your efforts,
Kevin
---...
2015 Jul 29
1
[LLVMdev] Error when i am using command make -j4 command in cygwin to compile safecode
...ing directory '/home/NIKHILREDDY/WORK/LLVM_OBJ/projects/poolalloc/lib/DSA'
llvm[4]: Compiling AddressTakenAnalysis.cpp for Release+Asserts build
llvm[4]: Compiling AllocatorIdentification.cpp for Release+Asserts build
llvm[4]: Compiling Basic.cpp for Release+Asserts build
llvm[4]: Compiling BottomUpClosure.cpp for Release+Asserts build
llvm[4]: Compiling CallTargets.cpp for Release+Asserts build
llvm[4]: Compiling CompleteBottomUp.cpp for Release+Asserts build
llvm[4]: Compiling DSCallGraph.cpp for Release+Asserts build
llvm[4]: Compiling DSGraph.cpp for Release+Asserts build
llvm[4]: Compiling DSTes...