similar to: [LLVMdev] Assertion failure in tablegen: rationale ?

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

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

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

On Dec 12, 2010, at 10:54 AM, Garrison Venn wrote: > > 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

Hi LLVMers, I found a bug in TGParser that is causing llvm-tblgen to crash on bad input. The reduced testcase is attached. The output follows: $ ./llvm-tblgen --version Low Level Virtual Machine (http://llvm.org/): LLVM version 3.1svn DEBUG build with assertions. Built Jan 20 2012 (15:46:08). Default target: x86_64-apple-darwin11.2.0 Host CPU: penryn $ ./llvm-tblgen bug.td 0

Hi Chris, Thanks for the review! I believe I caught most of the syntax style issues with the attached patch. It only contains these style changes. On Dec 12, 2010, at 19:30, Chris Lattner wrote: > > On Dec 12, 2010, at 10:54 AM, Garrison Venn wrote: > >> >> Hey Chris, >> >> The following patch removes all global references to a RecordKeeper instance for the

Hi all, How can I replace those "\" in the str? Thanks in advance. func <- function(str) { print(gsub("\\","",str)) } func("bla\ble\bli")

On Aug 1, 2012, at 1:53 PM, Jyotsna Verma <jverma at codeaurora.org> wrote: > > Currently, we rely on switch tables to transform between formats. However, > we would like to have a different mechanism to represent these relationships > instead of switch tables. I am thinking of modeling these relations in > HexagonInstrInfo.td file and use TableGen to generate a table with

Hello, I try this : in application_helper.rb ----------------------- def lnk bla return link_to bla, { :controller => bli , :action => "blo" , :id => "blu" } end in file.rhtml ----------- <%= lnk "yo!" %> This return an error. There is a way to do this or something similar, or this is completly impossible ? Thanks

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

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

Hi, I'm looking for some suggestions on a problem related to the Hexagon backend. Hexagon architecture allows instructions in various formats. For example, we have 3 variations of the add instruction as defined below: ADDrr : r1 = add(r2, r3) --> add 2 32-bit registers ADDrr_p : if(p0) r1 = add(r2, r3) --> predicated version of ADDrr instruction, executed when p0 is true ADDrr_np :

Oh yes you're right, I missed that :) But the point still hold. Amaury Pouly 2010/8/8 Eugene Toder <eltoder at gmail.com> > > Not only this code does not compile with NDEBUG set > > I may be missing something, but why does it not compile with -DNDEBUG? > assert() macro expands to noop when NDEBUG is set. > > Eugene > > On Sun, Aug 8, 2010 at 2:19 PM, Amaury

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