Assertion failure in tablegen: rationale ?

Project Infrastructure LLVM Dev List Archives
#1

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 = _t;
}

class Bla<list _bli>
: Bli<!car(_bli).t>
{
}

#0 0x00007ffff6ebda75 in *__GI_raise (sig=) at …/nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00007ffff6ec15c0 in *__GI_abort () at abort.c:92
#2 0x00007ffff6eb6941 in __GI___assert_fail (assertion=0x5aa663 “0 && “Unknown unop””, file=, line=633,
function=0x5abb20 "virtual llvm::RecTy llvm::UnOpInit::getFieldType(const std::string&) const") at assert.c:81
#3 0x000000000050ddc8 in llvm::UnOpInit::getFieldType (this=0x850f00, FieldName=…) at Record.cpp:633
#4 0x0000000000543f64 in llvm::TGParser::ParseValue (this=0x7fffffffd480, CurRec=0x8511d0, ItemType=0x851540) at TGParser.cpp:1342
#5 0x0000000000544574 in llvm::TGParser::ParseValueList (this=0x7fffffffd480, CurRec=0x8511d0, ArgsRec=0x8510d0, EltTy=0x0) at TGParser.cpp:1405
#6 0x000000000053e520 in llvm::TGParser::ParseSubClassReference (this=0x7fffffffd480, CurRec=0x8511d0, isDefm=false) at TGParser.cpp:397
#7 0x00000000005458e5 in llvm::TGParser::ParseObjectBody (this=0x7fffffffd480, CurRec=0x8511d0) at TGParser.cpp:1613
#8 0x00000000005463ad in llvm::TGParser::ParseClass (this=0x7fffffffd480) at TGParser.cpp:1727
#9 0x0000000000548b86 in llvm::TGParser::ParseObject (this=0x7fffffffd480, MC=0x0) at TGParser.cpp:2098
#10 0x0000000000548bbb in llvm::TGParser::ParseObjectList (this=0x7fffffffd480, MC=0x0) at TGParser.cpp:2107
#11 0x0000000000548c10 in llvm::TGParser::ParseFile (this=0x7fffffffd480) at TGParser.cpp:2115
#12 0x0000000000550035 in ParseFile (Filename=…, IncludeDirs=…, SrcMgr=…) at TableGen.cpp:196
#13 0x0000000000550116 in main (argc=3, argv=0x7fffffffe208) at TableGen.cpp:206

Looking at the code, it’s triggered because UnOpInit::getFieldType only handles the cast<> operator. I don’t see a good reason for this given that !car can give a value of which we can access a subfield. Of course, a trivial solution to the problem is to use !cast with !car but this seems ugly to me:

class Bli
{
string t = _t;
}

class Bla<list _bli>
: Bli<!cast(!car(_bli)).t>
{
}

Is this a bug or is it the wanted behaviour that a cast must be introduced ?
Regards

Amaury Pouly

#2

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 :slight_smile:

-Chris

#3

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(T.V).W
Example:

class Bla
{
string blu = t;
}

class Bli
{
Bla bla = t;
}

def a : Bli<Bla<"">>;
def b : Bla<!cast(a.bla).blu>; // works
def b : Bla<a.bla.blu>; // doesn’t work: Cannot access field ‘blu’ of value ‘a.bla’

Although these issue are not the same, there are similar in the sense that any Value of which the type is a class should have a working subfield lookup and should not require a cast. Except if I’m missing something and there is a real issue underneath.

Amaury Pouly

2010/9/1 Chris Lattner <clattner@apple.com>

#4

Chris Lattner <clattner@apple.com> writes:

#5

Amaury Pouly <amaury.pouly@gmail.com> writes:

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

Both problems fixed in 113010.

                      -Dave