search for: mcparser

Dear testers, 4.0.0-rc1 was just tagged from the branch, with r292377. There are still open merge requests and bugs, but I'd like to get the testing started to see what issues come up. Please build, test, and upload binaries to the sftp. Let me know how it goes. I'll upload source, docs, and your binaries to the web site once their ready. Thanks, Hans

...ser are target-independent. TargetAsmParser is deleted and all targets should interit from the object file that the asm parser understands (currently just MachOAsmParser). Note that there's a missing commit to clang (because this repo doesn't mirror the clang/ source). --- include/llvm/MC/MCParser/AsmParser.h | 51 +- include/llvm/MC/MCParser/MachOAsmParser.h | 56 +++ include/llvm/Target/TargetRegistry.h | 22 +- lib/CodeGen/AsmPrinter/AsmPrinterInlineAsm.cpp | 12 +- lib/MC/MCParser/AsmParser.cpp | 573 +--------------------- lib/MC/MCPars...

...ng " simple" in the low asm > layer appropriately? What am I missing? > > Thanks. > > include/llvm/MC/MCStreamer.h | 2 +- > lib/CodeGen/AsmPrinter/DwarfCFIException.cpp | 2 +- > lib/MC/MCAsmStreamer.cpp | 6 ++++-- > lib/MC/MCParser/AsmParser.cpp | 8 ++++++-- > lib/MC/MCStreamer.cpp | 2 +- > test/MC/AsmParser/cfi-startproc-simple.s | 7 +++++++ > 6 files changed, 20 insertions(+), 7 deletions(-) > create mode 100644 test/MC/AsmParser/cfi-startproc-simple.s > > diff...

...argument names, compilation would succeed. Such behavior is due to the glitch in AsmParser::expandMacro() logic: it treats first non-alphanumeric character as the end of argument instantiation token. Following patch fixes the issue (IsIdentifierChar routine implementation was borrowed from lib/MC/MCParser/AsmLexer.cpp): =================================================================== --- lib/MC/MCParser/AsmParser.cpp (revision 157279) +++ lib/MC/MCParser/AsmParser.cpp (working copy) @@ -1436,6 +1436,11 @@ NewDiag.print(0, OS); } +/// LexIdentifier: [a-zA-Z_.][a-zA-Z0-9_$.@]* +static bool...

...be 10 instead of 8. It seems asm parser treat "B = 3*A - 2 * A + 1" as "B = 3*A - (2 * A + 1)" because the second "*" has higher precedence than "-", and evaluation just performs simple recursion within AsmParser::ParseBinOpRHS (which resides in file lib/MC/MCParser/AsmParser.cpp). Can some one make a fixup? Regard. -- 杨勇勇 (Yang Yong-Yong) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130503/0325d37c/attachment.html>

...pe=box,style=filled,color=olivedrab1]; Target [shape=box,style=filled,color=olivedrab1]; System [shape=box,style=filled,color=olivedrab1]; Support [shape=box,style=filled,color=olivedrab1]; SelectionDAG [shape=box,style=filled,color=olivedrab1]; ScalarOpts [shape=box,style=filled,color=olivedrab1]; MCParser [shape=box,style=filled,color=olivedrab1]; MC [shape=box,style=filled,color=olivedrab1]; Linker [shape=box,style=filled,color=olivedrab1]; JIT [shape=box,style=filled,color=olivedrab1]; Interpreter [shape=box,style=filled,color=olivedrab1]; Instrumentation [shape=box,style=filled,color=olivedrab1];...

...::VPERMILPSYri:     DecodeVPERMILPSMask(8, MI->getOperand(2).getImm(),                         ShuffleMask);     Src1Name = getRegName(MI->getOperand(0).getReg()); The 'Src1Name' variable is assigned values twice successively. So break instruction should be at line 212. ---- lib/MC/MCParser/AsmLexer.cpp:149   while (CurChar != '\n' && CurChar != '\n' && CurChar != EOF) There are identical sub-expressions to the left and to the right of the '&&' operator: CurChar != '\n' && CurChar != '\n'. The second expression s...

On Aug 4, 2011, at 9:03 AM, Duncan Sands wrote: >> >> lib/MC/MCParser/AsmLexer.cpp:149 >> while (CurChar != '\n'&& CurChar != '\n'&& CurChar != EOF) >> >> There are identical sub-expressions to the left and to the right of the '&&' >> operator: CurChar != '\n'&& CurChar != &...

...ces. Is there a plan to rename lib/AsmParser as well? This directory name is somewhat misleading, because the code in it parses IR. In fact, nothing mentions AsmParser in the code inside that dir, except the build files. The name creates a confusion with other AsmParser citizens of LLVM like lib/MC/MCParser/AsmParser.cpp (which is an actual assembly parser, class AsmParser). Eli

...; > It seems asm parser treat "B = 3*A - 2 * A + 1" as "B = 3*A - (2 * A + 1)" > because the second "*" has higher precedence than "-", and evaluation just > performs simple recursion within AsmParser::ParseBinOpRHS (which resides in > file lib/MC/MCParser/AsmParser.cpp). > > Can some one make a fixup? This is a horrible bug :-( Can you please report it in llvm.org/bugs? Thanks, Rafael

I'm trying to add support for inline assembly and I keep getting this error: <jal> "<inline asm>:1:2: error: invalid instruction" which is due to the fact that MatchInstructionImpl() returns Match_MnemonicFail. This function is tablegen'ed in XXXGenAsmMatcher.inc and for some reason it can't find JAL even though I can clearly see it in both MatchTable0[] and

...ShuffleMask); > Src1Name = getRegName(MI->getOperand(0).getReg()); > > The 'Src1Name' variable is assigned values twice successively. So break > instruction should be at line 212. I've added the missing "break". > > ---- > > lib/MC/MCParser/AsmLexer.cpp:149 > while (CurChar != '\n'&& CurChar != '\n'&& CurChar != EOF) > > There are identical sub-expressions to the left and to the right of the '&&' > operator: CurChar != '\n'&& CurChar != '\n'. The...

...the potentially misleading lines so they can decide what do about the warnings (if anything). I'm wondering if clang-format is making some inappropriate choices here or these are just genuine mistakes. Anyway here are the ones I saw in passing. ``` /home/dsl11/dev/llvm-upstream/src/lib/MC/MCParser/DarwinAsmParser.cpp: In member function ‘bool {anonymous}::DarwinAsmParser::parseVersionMin(llvm::StringRef, llvm::SMLoc)’: /home/dsl11/dev/llvm-upstream/src/lib/MC/MCParser/DarwinAsmParser.cpp:962:3: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if (Update > 255 ||...

...cal/llvm-2.8/include/llvm/MC/MCLabel.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCMachOSymbolFlags.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCObjectStreamer.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCObjectWriter.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCParser -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCParser/AsmCond.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCParser/AsmLexer.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCParser/MCAsmLexer.h -- Installing: /usr/local/llvm-2.8/include/llvm/MC/MCParser/MCAsmParser.h -- Installi...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel

Dear Developers, I compile a OpenCL kernel, FFT, in AMDAPP SDK v2.5 using clang 3.8 + libclc and assembling the code with lld (The LLVM linker). The assembly code contains the following assembly codes (and lots of other similar format assembly) that fails to be parsed by AMDGPUAsmParser. It seems to me that both are valid instructions after looking at the SI instruction spec. s_mov_b32 s0,

Eli Friedman wrote: > Please file bug reports at llvm.org/bugs/ Filed bugs for all three. I was hoping to fix these now, with some help.

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