search for: armdisassembler

...WithWriteBack(llvm::SmallVectorImpl<llvm::MCParsedAsmOperand*>&)’: /home/greened/src/llvm-30-rc3/llvm/lib/Target/ARM/AsmParser/ARMAsmParser.cpp:1979:11: warning: variable ‘ExprLoc’ set but not used [-Wunused-but-set-variable] /home/greened/src/llvm-30-rc3/llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp: In function ‘DecodeStatus DecodeCopMemInstruction(llvm::MCInst&, unsigned int, uint64_t, const void*)’: /home/greened/src/llvm-30-rc3/llvm/lib/Target/ARM/Disassembler/ARMDisassembler.cpp:1241:12: warning: variable ‘idx_mode’ set but not used [-Wunused-but-set-variable] /home/greened/src/l...

On 7 November 2011 22:00, Bill Wendling <wendling at apple.com> wrote: > We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: > >        http://llvm.org/pre-releases/3.0/rc3/ > > for the sources. There are also binaries for Darwin up there, with more to come during the week. Please build this release candidate, test it out on your

Hello Tim, Rafael, Renato and llvmdev, I’m working to get llvm-objdump handle both arm and thumb disassembly from the same object file similarly to how darwin’s otool(1) works. And I’m looking for implementing direction. I spoke to Jim Grosbach about some ideas and he suggested I send out and email about some of the possibilities. Since none of the ones I could think of are pretty he thought

Good day, LLVMers! We are starting on our third (and hopefully last) round of testing for LLVM 3.0. Please visit: http://llvm.org/pre-releases/3.0/rc3/ for the sources. There are also binaries for Darwin up there, with more to come during the week. Please build this release candidate, test it out on your projects, and let us know if you find any regressions from the 2.9 release. Please keep

On Apr 8, 2013, at 2:55 PM, "Robinson, Paul" <Paul_Robinson at playstation.sony.com> wrote: I keep seeing "this is a layering violation" comments on the lists. > While there are a few llvm.org pages that mention layers in passing, > there is nothing (that I've found) actually specifying the layers. > Trying to infer the layering from the code is tedious and

I keep seeing "this is a layering violation" comments on the lists. While there are a few llvm.org pages that mention layers in passing, there is nothing (that I've found) actually specifying the layers. Trying to infer the layering from the code is tedious and error-prone (or we wouldn't see so many violations in code reviews, eh?). Now, I understand that Google has some sort

...rget/ARM/InstPrinter/Release+Asserts/ARMInstPrinter.o differ: byte 192432, line 305 ./lib/Target/ARM/AsmParser/Release+Asserts/ARMAsmParser.o ../../recurse2be/build/./lib/Target/ARM/AsmParser/Release+Asserts/ARMAsmParser.o differ: byte 665774, line 1708 ./lib/Target/ARM/Disassembler/Release+Asserts/ARMDisassembler.o ../../recurse2be/build/./lib/Target/ARM/Disassembler/Release+Asserts/ARMDisassembler.o differ: byte 352766, line 1109 ./lib/Target/ARM64/Release+Asserts/ARM64ISelDAGToDAG.o ../../recurse2be/build/./lib/Target/ARM64/Release+Asserts/ARM64ISelDAGToDAG.o differ: byte 190326, line 970 ./lib/Target/ARM...

Owen, As I recall, we had some similar issues with custom decoders needing to cooperate on ARM. Do you remember the details? -Jim On Dec 18, 2012, at 2:37 AM, Richard Osborne <richard at xmos.com> wrote: > I'm currently trying to get llvm-mc --disassemble working for the XCore backend. Up until recently there was no instruction encoding / decoding information on any of the XCore

I'm currently trying to get llvm-mc --disassemble working for the XCore backend. Up until recently there was no instruction encoding / decoding information on any of the XCore instructions so Im incrementally adding this information at the same time as adding tests for the disassembler. However I've run into a problem and I'm not sure of the best way to solve it. With some of the