Displaying 7 results from an estimated 7 matches for "unopinit".
Did you mean:
uninit
2010 Sep 01
3
[LLVMdev] Assertion failure in tablegen: rationale ?
...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:13...
2010 Sep 01
0
[LLVMdev] Assertion failure in tablegen: rationale ?
...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 TGPar...
2010 Sep 01
1
[LLVMdev] Assertion failure in tablegen: rationale ?
...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, ItemTyp...
2010 Dec 13
4
[LLVMdev] tblgen internals
...l for Record to have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it?
I'll see if I can come up with another approach. This internal reference was motivated by the
Record::setName(...) and UnOpInit::Fold(...) implementations accessing the previous
global RecordKeeper instance. We could add a RecordKeeper& argument to setName
and OpInit::Fold(...). However as I'm looking at the code, while adding this argument to Fold
for TGParser use is not an issue as it has a RecordKeeper instance,...
2010 Dec 13
0
[LLVMdev] tblgen internals
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
2010 Dec 13
0
[LLVMdev] tblgen internals
...have to have a RecordKeeper& in it. I haven't looked at the code in a long time, is it feasible to detangle that out of record, or is it not worth it?
>
> I'll see if I can come up with another approach. This internal reference was motivated by the
> Record::setName(...) and UnOpInit::Fold(...) implementations accessing the previous
> global RecordKeeper instance. We could add a RecordKeeper& argument to setName
> and OpInit::Fold(...). However as I'm looking at the code, while adding this argument to Fold
> for TGParser use is not an issue as it has a RecordK...
2010 Dec 12
2
[LLVMdev] tblgen internals
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