thr3ads.net - llvm dev - [LLVMdev] Assertion failure in tablegen: rationale ? [Sep 2010]

If this information is useful, please help other people find it:
Share via:

Amaury Pouly

2010-Sep-01 11:35 UTC

[LLVMdev] Assertion failure in tablegen: rationale ?

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>

Chris Lattner

2010-Sep-01 15:57 UTC

head link

[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 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

Amaury Pouly

2010-Sep-01 16:07 UTC

head link

[LLVMdev] Assertion failure in tablegen: rationale ?

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

head link

[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

Reasonably Related Threads

Search for more possibly parallel threads

llvm dev - Sep 2010 - [LLVMdev] Assertion failure in tablegen: rationale ?

[LLVMdev] Assertion failure in tablegen: rationale ?

[LLVMdev] Assertion failure in tablegen: rationale ?

[LLVMdev] Assertion failure in tablegen: rationale ?

[LLVMdev] Assertion failure in tablegen: rationale ?

Reasonably Related Threads