similar to: [LLVMdev] Increase the flexibility of the AsmLexer in parsing identifiers.

Hello, I've noticed a following strange behavior: clang-3.2 fails to compile/parse any assembly code that invokes macros which named arguments contains non alphanumeric characters. For example, compilation of the following code snippet would fail with "Parameter not found" error: .macro mov_macro reg_1, reg_2 movl %\reg_1, %\reg_2 .endm mov_macro eax, ebx Although, if one

The attached patch implements simple target-specific AsmLexers for ARM and Thumb. They are shallow subclasses of a common tokenizer that uses a std::map of register names to IDs to recognize register names, and reports those as AsmToken::Register tokens instead of identifiers. I intend to use the ARM and Thumb AsmLexers as part of an extension of the EnhancedDisassembly library, which provides

Hi Daniel, attached is a patch that pushes most of the object file specific parsing out of AsmParser and down into MachOAsmParser. This was done as a cleanup for the ELF work. I know that you're not happy with this approach, particularly the fact that as we add more object file formats and assembler dialects, it's going to cause a class explosion. But I was hoping that we could use this

> Hmm..., the crux of not being able to lex arithmetic expressions seems to > be due to lack of context sensitivity. E.g. consider `foo*bar`. Could be a > multiplication, or could be a glob pattern. > > Looking at the code more closely, adding context sensitivity wouldn't be > that hard. In fact, our ScriptParserBase class is actually a lexer (look at > the interface; it

On Tue, Jan 24, 2017 at 11:29 AM, Rui Ueyama <ruiu at google.com> wrote: > Well, maybe, we should just change the Linux kernel instead of tweaking > our tokenizer too hard. > This is silly. Writing a simple and maintainable lexer is not hard (look e.g. at https://reviews.llvm.org/D10817). There are some complicated context-sensitive cases in linker scripts that break our approach

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 != '\n'. The

Hi. There are few one-line bugs Andrey Karpov have found with static analisys. He wrote a big article in russian on http://habrahabr.ru/blogs/compilers/125626/ for advertising purposes of static analyzer for Visual Studio his company developed. Most of the problems are easy to fix, so I list them in here for trunk version. Also few problems in clang code were found, I don't list them in here.

On Fri, Jan 27, 2017 at 1:31 PM, Rui Ueyama <ruiu at google.com> wrote: > Sean, > > So as you noticed that linker script tokenization rule is not very trivial > -- it is context sensitive. The current lexer is extremely simple and > almost always works well. Improving "almost always" to "perfect" is not > high priority because we have many more high

Hi Lockal S, > ---- > > lib/Target/X86/X86ISelLowering.cpp:11689 > !DAG.isKnownNeverZero(LHS)&& !DAG.isKnownNeverZero(LHS)) > > Note that there are identical subexpressions '!DAG.isKnownNeverZero (LHS)' to > the left and to the right of the '&&' operator. > The second subexpression should probably be !DAG.isKnownNeverZero(RHS)). a patch

A friendlier error message in that situation is definitely a good thing. -Jim On Sep 5, 2011, at 1:34 PM, Степан wrote: > Hi, everybody. > > I am a newbie in llvm development. I found some strange behaviour in llvm-mc. Files without empty string at the eof doesn't proceed properly. > > llvm-mc prints something like this: > <stdin>:5:18: error: unexpected token in

Hi, everybody. I am a newbie in llvm development. I found some strange behaviour in llvm-mc. Files without empty string at the eof doesn't proceed properly. llvm-mc prints something like this: <stdin>:5:18: error: unexpected token in argument list It looks like a bug. At least we should print: <stdin>:5:18: error: no newline at the end of file! If yes, I create it in bugzilla

Hi ES, From what I understand instruction parsing is divided into two parts: - Parsing an operand list (XXXAsmParser::ParseInstruction) - Turning the operand list into an actual instruction (XXXAsmParser::MatchAndEmitInstruction) The second part does the validation (e.g. how many operands, what kind, etc) while the first part only does the parsing. That's why I think in the first part

The is a syntax quirk in TableGen. A leading plus or minus sign on a decimal integer is considered part of the integer token. Coupled with this, the hyphen (-) is used to indicate integer ranges, as in '1-5'. But the compiler lexes '1-5' as '1' followed by '-5', so a special rule is required to treat that as a range. It is documented as follows: "The peculiar

Hi everyone, TL;DR: With current pending patches applied in compiler-rt and llvm, and trunk clang, you can build your application with XRay tracing enabled on Linux with tracing enabled before main starts, and logging stops when the main thread exits. Just a quick update, I have some patches under review that when applied cleanly to LLVM and compiler-rt allows for building applications with XRay

Ok, here is the patch again... I also included fixes for the bits that originally gave my mailer fits... Two votes for orange, so I went with orange... Doing diffs in .: --- ./lib/AsmParser/LLLexer.cpp.~1~ 2007-12-14 22:09:06.000000000 -0800 +++ ./lib/AsmParser/LLLexer.cpp 2007-12-15 13:02:47.000000000 -0800 @@ -54,7 +54,7 @@ static uint64_t HexIntToVal(const char * Result +=

On Sunday 25 November 2007 05:28, Aaron Gray wrote: > > On Sunday 25 November 2007 03:42, Christopher Lamb wrote: > >> Try this google query. I know there's been some discussion/work on > >> OCaml and LLVM. > >> > >> site:lists.cs.uiuc.edu/pipermail/llvmdev OCaml interface > > > > I just rediscovered the OCaml bindings in bindings/ocaml

On 01.04.20 14:50, Jason Wang wrote: > > On 2020/4/1 ??7:21, Christian Borntraeger wrote: >> On 26.03.20 15:01, Jason Wang wrote: >>> Currently, CONFIG_VHOST depends on CONFIG_VIRTUALIZATION. But vhost is >>> not necessarily for VM since it's a generic userspace and kernel >>> communication protocol. Such dependency may prevent archs without >>>

On 01.04.20 14:50, Jason Wang wrote: > > On 2020/4/1 ??7:21, Christian Borntraeger wrote: >> On 26.03.20 15:01, Jason Wang wrote: >>> Currently, CONFIG_VHOST depends on CONFIG_VIRTUALIZATION. But vhost is >>> not necessarily for VM since it's a generic userspace and kernel >>> communication protocol. Such dependency may prevent archs without >>>

Please commit... Best Olaf Krzikalla -- Olaf Krzikalla Technische Universitaet Dresden Zentrum fuer Informationsdienste und Hochleistungsrechnen Abteilung Verteiltes und Datenintensives Rechnen Zellescher Weg 12, 01069 Dresden Willersbau, Zimmer A105 Telefonnr.: +49 351 463-32442 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: twine.patch

On 2020/4/1 ??9:02, Christian Borntraeger wrote: > > On 01.04.20 14:56, Christian Borntraeger wrote: >> On 01.04.20 14:50, Jason Wang wrote: >>> On 2020/4/1 ??7:21, Christian Borntraeger wrote: >>>> On 26.03.20 15:01, Jason Wang wrote: >>>>> Currently, CONFIG_VHOST depends on CONFIG_VIRTUALIZATION. But vhost is >>>>> not necessarily