similar to: [LLVMdev] Update CMakeLists.txt for Target Hexagon to adjust MCTargetDesc path for HexagonMCAsmInfo.cpp

Displaying 12 results from an estimated 12 matches similar to: "[LLVMdev] Update CMakeLists.txt for Target Hexagon to adjust MCTargetDesc path for HexagonMCAsmInfo.cpp"

2011 Dec 16
0
[LLVMdev] Update CMakeLists.txt for Target Hexagon to adjust MCTargetDesc path for HexagonMCAsmInfo.cpp
My apologies. Shouldn't it just be removed since it is now in a subdirectory? On 12/15/2011 11:38 PM, Marc J. Driftmeyer wrote: > File: trunk/llvm/lib/Target/Hexagon/CMakeLists.txt > > set(LLVM_TARGET_DEFINITIONS Hexagon.td) > > tablegen(LLVM HexagonGenRegisterInfo.inc -gen-register-info) > tablegen(LLVM HexagonGenInstrInfo.inc -gen-instr-info) > tablegen(LLVM
2012 Nov 13
2
[LLVMdev] [PATCH] .gitignore: add rules for a clean worktree
Add several .gitignore rules to various directories to ensure a clean worktree after a default build. Signed-off-by: Ramkumar Ramachandra <artagnon at gmail.com> --- Just cloned and built LLVM. This annoyed me. Here's a trivial patch. .gitignore | 10 ++++++++++ bindings/ocaml/llvm/.gitignore | 1 + docs/.gitignore
2008 Oct 26
0
[LLVMdev] Keeping CMakeLists.txt up-to-date.
Óscar Fuentes wrote: > Kenneth Boyd <zaimoni at zaimoni.com> writes: > > > ..... >> From the existence of the dependency-tracker scripts, it obviously was >> a problem for autoconf as well. >> > > This seems a different issue, but are those dependency-tracker scripts > for tracking dependencies among cpp files and its headers? CMake gives >
2010 Dec 20
1
[LLVMdev] [LLVMDev] CmakeLists.txt in Codegen is not current
Like the title says, the CMakeLists.txt does not contain the current information. Attached is a patch to fix it. - Thanks, Jeff Kunkel -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101220/285746bf/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name:
2015 Jul 28
0
[LLVMdev] llvmbuild.txt and cmakelists.txt
I've been experimenting with building various llvm variants on mac OS X. Ususally, it's a case of cloning, running cmake with Xcode as generator and loading the resulting xcodeproj. In trying to build the skeleton openrisc backend from https://github.com/asl/llvm-openrisc as described in "building a backend in 24 hours" at
2008 Oct 26
1
[LLVMdev] Keeping CMakeLists.txt up-to-date.
Kenneth Boyd <zaimoni at zaimoni.com> writes: >> 1) either CMake becomes the de facto standard for LLVM, deprecating >> autoconf&&gmake and thus requiring the developers to update the >> CMakeLists.txt files to compile their sources... >> > Sorry, but this is a noticeable obstacle for CMake becoming the de-facto > standard for LLVM. Writing a new
2016 Nov 11
2
initialization-order-fiasco in MCTargetDesc/X86MCAsmInfo.cpp
Mehdi, Teresa, Not sure if this is caused by one of your recent commits, or by someone else's, please excuse me if that's unrelated to your work... http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/542/steps/check-llvm%20asan/logs/stdio ==26383==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x000002ef41d8 at pc 0x0000009d1aa5 bp 0x7ffd0cd72b50 sp
2012 May 29
1
[LLVMdev] [cfe-commits] r157260 - in /cfe/trunk: include/clang/Rewrite/Rewriter.h lib/Rewrite/Rewriter.cpp unittests/CMakeLists.txt unittests/Tooling/RewriterTest.cpp unittests/Tooling/RewriterTestContext.h
Manuel, After the discussion at last night, I have agreed that GetTemporaryDirectory() on Win32 would do bad thing, thank you. dir = GetTemporaryDirectory(); dir.eraseFromDisk(erase_contents = true); dir = GetTemporaryDirectory(); /* It doesn't create anything on Win32 due to caching */ I suppose Manuel wants GetTemporaryDirectory() to keep semantics similar mkdtemp(3). Though it is in
2013 Jan 11
1
[LLVMdev] SMFixIt helps break TableGen in Trunk
Trunk output: > [ 32%] Building CXX object > examples/Kaleidoscope/Chapter3/CMakeFiles/Kaleidoscope-Ch3.dir/toy.cpp.o > /home/mdriftmeyer/DeveloperProjects/LLVMProject/trunk/llvm/tools/clang/utils/TableGen/ClangDiagnosticsEmitter.cpp:158:17: > error: > no member named 'getSuperClassRanges' in 'llvm::Record'; did you > mean 'getSuperClasses'? >
2014 Apr 03
5
[LLVMdev] comparing .o files from different build trees
I'm trying to write a script for checking whether the compiler recursed properly. rkotler at mipsswbrd002:~/slave/recurse3be/build$ find . -name "*.o" -exec cmp '{}' ../../recurse2be/build/'{}' \; |& tee foo.txt Is anyone else doing this? There 2 compilers, recurse 2 and recurse3 that in principle should be identical. Obviously if there is date and time
2015 Jun 04
2
[LLVMdev] Assert in BlockFrequency pass
> On 2015-Jun-04, at 12:45, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > >> On 2015-Jun-04, at 12:28, Ivan Baev <ibaev at codeaurora.org> wrote: >> >> Hi, we got the following assert: >> >> assert(!Working[0].isLoopHeader() && "entry block is a loop header"); >> >> [in
2012 Apr 19
0
[LLVMdev] Target Dependent Hexagon Packetizer patch
Sure I will split it and put it in two patches. Give me few hours. I need to test those patches. Sirish On 4/19/2012 8:40 AM, Tom Stellard wrote: > On Wed, Apr 18, 2012 at 11:18:05PM -0500, Sirish Pande wrote: >> Hi, >> >> Here's a patch for Hexagon Packetizer for review. This patch does >> not yield any warnings. >> > Would it be possible to split this