similar to: [LLVMdev] TableGen Crash

Hello, I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): class Bli<string _t> { string t = _t; } class Bla<list<Bli> _bli> : Bli<!car(_bli).t> { } #0 0x00007ffff6ebda75 in *__GI_raise

On Sep 1, 2010, at 4:35 AM, Amaury Pouly wrote: > Hello, > I was fiddling with TableGen (for a use that has nothing to do with a compiler but it's doesn't matter) and TableGen triggers an assertion failure on this code (I reduced the case to the minimum, it's a parsing bug): David, can you take a look? This is related to your lisp interpreter :) -Chris > > class

While I'm at it, I noticed a behaviour which is not exactly related but similar. To put it simply, you can 't do T.V.W, you need to do !cast<Bla>(T.V).W Example: class Bla<string t> { string blu = t; } class Bli<Bla t> { Bla bla = t; } def a : Bli<Bla<"">>; def b : Bla<!cast<Bla>(a.bla).blu>; // works def b :

Hello everyone, I bring to discussion the necessity/design of a new type of smart pointer. r215176 and r217791 rise the problem, D5443 <http://reviews.llvm.org/D5443> is devoted to the solution. r215176 applies several temporary ugly fixes of memory leaks in TGParser.cpp which would be great to be refactored using smart pointers. D5443 <http://reviews.llvm.org/D5443> demonstrates

On Wed, Oct 1, 2014 at 3:14 PM, Anton Yartsev <anton.yartsev at gmail.com> wrote: > Ping! > > Suggested is a wrapper over a raw pointer that is intended for freeing > wrapped memory at the end of wrappers lifetime if ownership of a raw > pointer was not taken away during the lifetime of the wrapper. > The main difference from unique_ptr is an ability to access the wrapped

Hi Everyone, After some more thoughts to the Jacob's suggestion of using multiclasses for Opcode mapping, this is what I have come up with. Please take a look at the design below and let me know if you have any suggestions/questions. I have tried to keep the design target independent so that other targets could benefit from it. 1) The idea is to add 3 new classes into

I've been trying to get llvm to compile under windows with the Intel C+ + 11.0.066 compiler without killing the compiler. I filed a bug report with Intel, and Intel says that their compiler has a problem with RecTy and Init being declared with "class" in utils \TableGen\TGParser.h but defined with "struct" in utils\TableGen \Record.h. The attached patch changes

Seems to just be a byproduct of TGParser::AddSubClass() begin called twice. This means that TGParser::AddValue() is being called once for the "i" of each class, and the "last one wins". Not sure if it is intended, but this behavior seems to more-or-less "make sense". --Sean Silva On Mon, Jul 2, 2012 at 4:55 PM, reed kotler <rkotler at mips.com> wrote: >

Hi All, One thing I believe also bothers someone else. Say we have the following code snippet: bits<32> insnEncoding; let insnEncoding{15-12} = 0b0100; Can we write the let expression with range list like this, with the same meaning? let insnEncoding{12-15} = 0b0100; I take a look on TGParser::ParseRangePiece (lib/TableGen/TGParser.cpp), seems the answer is YES. Can anyone

Attached patch for removing for the first trivial RecordKeeper:: getAllDerivedDefinitions(...) dependency on the global RecordKeeper Records instance. The real work will be removing this dependency from the other Record.h classes/structs, and from TGParser. Thinking this would be implemented as some sort of context structure/class holding a RecordKeeper instance passed to TGParser which in turn

My purpose is to eliminate copy-paste style of programming in td files as much as possible, but only to a point that the new language constructs do not create too much overhead/readability-downgrade. In other words, I am targeting those low-hanging fruit of copy-paste programmings in td files that are eliminated by a simple for-loop syntax. The repetitive patterns I observed in PTX backend (and

Hi Jakob, How is `FieldName`, which is a std::string, being passed as the third argument to SetValue on line 1848 of TGParser.cpp, which is declared as being an Init*? The nearly identical (FIXME) codepath in ParseDeclaration immediately puts the string into a StringInit, which makes sense, but how on earth is the std::string being passed in? This is really freaking me out. -- Sean Silva

I made a simple edit to TGlexer.h, which is part of TableGen. Then, in Visual Studio, I asked it to build Tablegen. I got the following output: 1>------ Build started: Project: LLVMTableGen, Configuration: Release x64 ------ 1>Main.cpp 1>TGLexer.cpp 1>TGParser.cpp 1>LLVMTableGen.vcxproj -> D:\LLVM\Build\Release\lib\LLVMTableGen.lib ========== Build: 1 succeeded, 0 failed, 3

On Wed, Sep 24, 2014 at 7:50 PM, Justin Bogner <mail at justinbogner.com> wrote: > Anton Yartsev <anton.yartsev at gmail.com> writes: > > Hello everyone, > > > > I bring to discussion the necessity/design of a new type of smart > pointer. > > r215176 and r217791 rise the problem, D5443 is devoted to the solution. > > r215176 applies several

Che-Liang Chiou <clchiou at gmail.com> writes: > My purpose is to eliminate copy-paste style of programming in td files > as much as possible, but only to a point that the new language > constructs do not create too much overhead/readability-downgrade. Yes! > In other words, I am targeting those low-hanging fruit of copy-paste > programmings in td files that are eliminated

Hey Chris, The following patch removes all global references to a RecordKeeper instance for the tblgen utility. This effort was motivated by the FIXME remark, in TableGen.cpp. Although a few files were touched, the main change was to Record.h. The patch takes the simple approach of adding a RecordKeeper reference to TGParser, and any needed emitter helper classes. In addition, since some of

Not sure what you mean. I.OutOperandList == (outs CPU16Regs:$rx) I.InOperandList == (ins CPU16Regs:$ry, CPU16Regs:$rz) On 07/02/2012 09:26 PM, Sean Silva wrote: > I think you're missing the template args for `FRRR16_ins` in the first > argument. The switch in TGParser::ParseType() doesn't cover the case > of types with template args though... which makes me wonder what is

Thanks for the feedback! > > On Wed, Oct 1, 2014 at 3:36 PM, David Blaikie <dblaikie at gmail.com > <mailto:dblaikie at gmail.com>> wrote: > > On Wed, Oct 1, 2014 at 3:14 PM, Anton Yartsev > <anton.yartsev at gmail.com <mailto:anton.yartsev at gmail.com>> wrote: > > Ping! > > Suggested is a wrapper over a raw pointer

I have submitted a patch to Phabricator that includes the TableGen file TGparser.cpp. Now I want to fix a bug in that file. What is the proper procedure so that the two patches don't get screwed up, either in my repository or in the master repository? Please answer as if I'm a git/Phabricator idiot, because, well, I am. I should note that all I did in my repository for the first patch was

I think you're missing the template args for `FRRR16_ins` in the first argument. The switch in TGParser::ParseType() doesn't cover the case of types with template args though... which makes me wonder what is going on inside of TableGen to make `I.f` and `I.AsmString` valid... --Sean Silva On Mon, Jul 2, 2012 at 8:07 PM, reed kotler <rkotler at mips.com> wrote: > I've filed