search for: metadata_attach

...t;::operator[](unsigned int) + 77 > 7   lli             0x0000000000850ce0 > llvm::BitcodeReader::ParseMetadataAttachment() + 448 > 8   lli             0x0000000000851043 Looks like a bug in the following piece of code, from BitcodeReader::ParseMetadataAttachment(): 1601 case bitc::METADATA_ATTACHMENT: { 1602 unsigned RecordLength = Record.size(); 1603 if (Record.empty() || (RecordLength - 1) % 2 == 1) 1604 return Error ("Invalid METADATA_ATTACHMENT reader!"); 1605 Instruction *Inst = InstructionList[Record[0]]; 1606 for (unsigned i = 1; i...

...;> 7 lli 0x0000000000850ce0 >> llvm::BitcodeReader::ParseMetadataAttachment() + 448 >> 8 lli 0x0000000000851043 > > Looks like a bug in the following piece of code, from > BitcodeReader::ParseMetadataAttachment(): > > 1601 case bitc::METADATA_ATTACHMENT: { > 1602 unsigned RecordLength = Record.size(); > 1603 if (Record.empty() || (RecordLength - 1) % 2 == 1) > 1604 return Error ("Invalid METADATA_ATTACHMENT reader!"); > 1605 Instruction *Inst = InstructionList[Record[0]]; > 1606...

Hi,all I tried to run the generated whole-program bitcode of BIND,but I got some information: 0 lli 0x0000000000feda16 1 lli 0x0000000000fed88f 2 libpthread.so.0 0x0000003df340eee0 3 libc.so.6 0x0000003df28332f5 gsignal + 53 4 libc.so.6 0x0000003df2834b20 abort + 384 5 libc.so.6 0x0000003df282c2fa __assert_fail + 234 6 lli

...bitcode. There are currently two blocks with the METADATA_BLOCK id at module scope. The first has the module-level metadata values (consisting of some combination of METADATA_* record codes except for METADATA_KIND). The second consists only of METADATA_KIND records. The latter is used only in the METADATA_ATTACHMENT block within function blocks (for metadata attached to instructions). For ThinLTO we want to delay the parsing of module level metadata until all functions have been imported from that module (there is some bookkeeping used to suture it up when we read it during a post-pass). However, I do nee...