search for: graphprinter

...B.getName() << "' with LHS: " > << *LHS << " and RHS: " << *RHS); > LastFailure = FailString + BB.getName().str(); >> >>> Since the >>> variable "LastFailure" is only used in ScopGraphPrinter, which should >>> only show critical information in graph, I hope such modification is >>> acceptable. >> >> Why should we only show critical information? In the GraphPrinter we do >> not worry about compile time so much, such that we can easily show >> hel...

...FailString << BB.getName() << "' with LHS: " << *LHS << " and RHS: " << *RHS); LastFailure = FailString + BB.getName().str(); > >> Since the >> variable "LastFailure" is only used in ScopGraphPrinter, which should >> only show critical information in graph, I hope such modification is >> acceptable. > >Why should we only show critical information? In the GraphPrinter we do >not worry about compile time so much, such that we can easily show >helpful information. We just n...

...only has little affects on the variable "LastFailure", > while keeping all information for DEBUG information. Why is that? It seems the DEBUG output is the very same that gets written to "LastFailure". > Since the > variable "LastFailure" is only used in ScopGraphPrinter, which should > only show critical information in graph, I hope such modification is > acceptable. Why should we only show critical information? In the GraphPrinter we do not worry about compile time so much, such that we can easily show helpful information. We just need to make sure that we...

..."' with LHS: " >> << *LHS << " and RHS: " << *RHS); >> LastFailure = FailString + BB.getName().str(); >>> >>>> Since the >>>> variable "LastFailure" is only used in ScopGraphPrinter, which should >>>> only show critical information in graph, I hope such modification is >>>> acceptable. >>> >>> Why should we only show critical information? In the GraphPrinter we do >>> not worry about compile time so much, such that we can easi...

...ondich/ParallelAssert/llvm-objects/Debug+Asserts/lib -o /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/Debug+Asserts/bin/opt /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/AnalysisWrappers.o /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/GraphPrinters.o /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/PrintSCC.o /n/fs/scratch/tpondich/ParallelAssert/llvm-objects/tools/opt/Debug+Asserts/opt.o \ -lLLVM-2.9svn -lpthread -lmalloc -lm Undefined first referenced symbol in...

> ... and it's in.  Please let me know if you see any problems. My clang self-hosted build (Release+Asserts on Release+Asserts, Linux x86_64) fails with: make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build clang: /home/jay/svn/llvm-project/llvm/trunk/include/llvm/Support/Casting.h:194: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X = llvm::FunctionType, Y = llvm::Type*, typename llvm::cast_retty<To, From>::ret_type = llvm::Funct...

...vm-config' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/d/Apps/llvm/tools/llvm-config' The system cannot find the path specified. make[2]: Entering directory `/d/Apps/llvm/tools/opt' llvm[2]: Compiling AnalysisWrappers.cpp for Release build llvm[2]: Compiling GraphPrinters.cpp for Release build llvm[2]: Compiling PrintSCC.cpp for Release build llvm[2]: Compiling opt.cpp for Release build make[2]: *** No rule to make target `/lib/libLLVMTransforms.a', needed by `/d/Apps/llvm/Release/bin/opt.exe'. Stop. make[2]: Leaving directory `/d/Apps/llvm/tools/opt...

.../work/llvm-9999-abi_x86_64.amd64/tools/opt/Release/AnalysisWrappers.o /mnt/daten/Daten/Workspace/portage/sys-devel/llvm-9999/work/llvm-9999-abi_x86_64.amd64/tools/opt/Release/BreakpointPrinter.o /mnt/daten/Daten/Workspace/portage/sys-devel/llvm-9999/work/llvm-9999-abi_x86_64.amd64/tools/opt/Release/GraphPrinters.o /mnt/daten/Daten/Workspace/portage/sys-devel/llvm-9999/work/llvm-9999-abi_x86_64.amd64/tools/opt/Release/NewPMDriver.o /mnt/daten/Daten/Workspace/portage/sys-devel/llvm-9999/work/llvm-9999-abi_x86_64.amd64/tools/opt/Release/PassPrinters.o /mnt/daten/Daten/Workspace/portage/sys-devel/llvm-9999/wo...

...ing if-statement: > if (::llvm::DebugFlag && ::llvm::isCurrentDebugType(TYPE)) > That means string operations controlled by DEBUG will not execute in normal case, so we should not worry about it. > 2) The other case is for the variable "LastFailure", which is used only in GraphPrinter. Currently string operations for "LastFailure" always execute in normal cases. My idea is to put such string operations under the condition of "GraphPrinter" mode. For example, I would like to translate the "INVALID" macro into: > #define INVALID(NAME, MESSAGE)...

Hello, > make[1]: *** [/d/apps/llvm/tools/llvm-config/LibDeps.txt] Error 127 > make[1]: Leaving directory `/d/apps/llvm/tools/llvm-config' > make: *** [all] Error 1 > > It seems as though GenLibDeps.pl does not exist but in fact it does exist in > that directory. I am baffled by that. > I don't really know much about Perl so I can't say if it failed while >

> I don't know anything about Solaris, but your paste doesn't actually > contain any errors, just warnings (unless I'm reading "ld: warning: > relocation error:" wrong). It might help to run make without -j until > it fails, and then use `make VERBOSE=1` to print the exact commands > it's running. Sorry. There was so much output I wasn't sure how much

...ay Foad wrote: >> ... and it's in. Please let me know if you see any problems. > > My clang self-hosted build (Release+Asserts on Release+Asserts, Linux > x86_64) fails with: > > make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' > llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build > clang: /home/jay/svn/llvm-project/llvm/trunk/include/llvm/Support/Casting.h:194: > typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) > [with X = llvm::FunctionType, Y = llvm::Type*, typename > llvm::cast_retty<To, From>::re...

...le-shared --prefix=/usr/local/llvm --- llvm[2]: Compiling llc.cpp for Release build gmake[2]: Entering directory `/tmp/llvm-build/2.7/llvm-objects/tools/llvm-ld' llvm[2]: Compiling Optimize.cpp for Release build llvm[2]: Linking Release executable llvm-dis (without symbols) llvm[2]: Compiling GraphPrinters.cpp for Release build /tmp/llvm-build/2.7/llvm-objects/tools/llvm-dis/Release/llvm-dis.o(.text+0x42): In function `main': : undefined reference to `llvm::sys::PrintStackTraceOnErrorSignal()' /tmp/llvm-build/2.7/llvm-objects/tools/llvm-dis/Release/llvm-dis.o(.text+0x51): In function `main...

...ment: >> if (::llvm::DebugFlag && ::llvm::isCurrentDebugType(TYPE)) >> That means string operations controlled by DEBUG will not execute in normal case, so we should not worry about it. >> 2) The other case is for the variable "LastFailure", which is used only in GraphPrinter. Currently string operations for "LastFailure" always execute in normal cases. My idea is to put such string operations under the condition of "GraphPrinter" mode. For example, I would like to translate the "INVALID" macro into: >> #define INVALID(NAME, MESSAGE)...

On Jul 9, 2011, at 12:35 AM, Chris Lattner wrote: > FYI, the type-system-rewrite branch is landing tomorrow morning, in mainline llvm, llvm-gcc and clang. I don't have updates, so dragonegg will have to remain broken until someone can fix it (the changes aren't too terrible, llvm-gcc is a good template). > > If you're interested in an early preview, the type-system-rewrite

LLVM SVN r45024 fails to complete building at the linker stage on my Virtual Private Linux server running Debian Etch with GCC 4.1.2. ---- sanitized snippet of make output ---- llvm[2]: Compiling llvm-as.cpp for Debug build llvm[2]: Compiling AnalysisWrappers.cpp for Debug build llvm[2]: Compiling GraphPrinters.cpp for Debug build llvm[2]: Linking Debug executable llvm-as llvm[2]: Compiling PrintSCC.cpp for Debug build llvm[2]: Compiling opt.cpp for Debug build llvm[2]: Linking Debug executable opt llvm[2]: ======= Finished Linking Debug Executable llvm-as make[2]: Leaving directory `~/llvm/tools/llvm-as...

...Coroutines IPO IRReader InstCombine Instrumentation MC ObjCARCOpts ScalarOpts Support Target TransformUtils Vectorize Passes ExecutionEngine ) # Support plugins. set(LLVM_NO_DEAD_STRIP 1) add_llvm_tool(opt AnalysisWrappers.cpp BreakpointPrinter.cpp Debugify.cpp GraphPrinters.cpp NewPMDriver.cpp PassPrinters.cpp PrintSCC.cpp opt.cpp DEPENDS intrinsics_gen ) export_executable_symbols(opt) if(WITH_POLLY AND LINK_POLLY_INTO_TOOLS) target_link_libraries(opt PRIVATE Polly) endif(WITH_POLLY AND LINK_POLLY_INTO_TOOLS) target_link_libraries(opt PUBLIC LLVMExe...

...() const' Apparently it's not being linked with libLLVMCore.a among other libs. The command line it's using is: cd /C/Development/llvm-2.5/tools/opt && /C/Development/llvm-gcc/bin/llvm-g++.exe "CMakeFiles/opt.dir/AnalysisWrappers.cpp.obj" "CMakeFiles/opt.dir/GraphPrinters.cpp.obj" "CMakeFiles/opt.dir/PrintSCC.cpp.obj" "CMakeFiles/opt.dir/opt.cpp.obj" -o ../../bin/opt.exe -Wl,--out-implib,../../lib/libopt.dll.a -Wl,--major-image-version,0,--minor-image-version,0 ../../lib/libLLVMipo.a ../../lib/libLLVMScalarOpts.a ../../lib/libLLVMInst...

...... and it's in. Please let me know if you see any problems. >> >> My clang self-hosted build (Release+Asserts on Release+Asserts, Linux >> x86_64) fails with: >> >> make[2]: Entering directory `/home/jay/llvm/objdir-self/tools/opt' >> llvm[2]: Compiling GraphPrinters.cpp for Debug+Asserts build >> clang: /home/jay/svn/llvm-project/llvm/trunk/include/llvm/Support/Casting.h:194: >> typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) >> [with X = llvm::FunctionType, Y = llvm::Type*, typename >> llvm::cast_retty<...

...l/llvm --- > llvm[2]: Compiling llc.cpp for Release build > gmake[2]: Entering directory > `/tmp/llvm-build/2.7/llvm-objects/tools/llvm-ld' > llvm[2]: Compiling Optimize.cpp for Release build > llvm[2]: Linking Release executable llvm-dis (without symbols) > llvm[2]: Compiling GraphPrinters.cpp for Release build > /tmp/llvm-build/2.7/llvm-objects/tools/llvm-dis/Release/llvm-dis.o(.text+0x42): > In function `main': > : undefined reference to `llvm::sys::PrintStackTraceOnErrorSignal()' > /tmp/llvm-build/2.7/llvm-objects/tools/llvm-dis/Release/llvm-dis.o(.text+0x51):...