[LLVMdev] Assertion failure in tablegen: rationale ?

[Chris Lattner]

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 Bli<string _t>
> {
>     string t = _t;
> }
> 
> class Bla<list<Bli> _bli>
> : Bli<!car(_bli).t>
> {
> }
> 
> #0  0x00007ffff6ebda75 in *__GI_raise (sig=<value optimized out>) 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=<value optimized out>, 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>
> {
>     string t = _t;
> }
> 
> class Bla<list<Bli> _bli>
> : Bli<!cast<Bli>(!car(_bli)).t>
> {
> }
> 
> Is this a bug or is it the wanted behaviour that a cast must be introduced ?
> Regards
> 
> 
> Amaury Pouly
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev