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 (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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100901/b043a6a5/attachment.html>
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
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 : 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 at apple.com>> > 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100901/00223375/attachment.html>
David A. Greene
2010-Sep-02 19:43 UTC
[LLVMdev] Assertion failure in tablegen: rationale ?
Chris Lattner <clattner at apple.com> writes:> 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 :)Ok. I've got to update a few things. I also have a few other fixes in this area. -Dave
Seemingly Similar Threads
- [LLVMdev] Assertion failure in tablegen: rationale ?
- [LLVMdev] Assertion failure in tablegen: rationale ?
- [LLVMdev] Usage of pointers to elements of a std::vector that might be reallocated
- [LLVMdev] Usage of pointers to elements of a std::vector that might be reallocated
- [LLVMdev] Usage of pointers to elements of a std::vector that might be reallocated