Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

bcwriter turns <2 x i10> into <2 x opaque> #1566

Closed
llvmbot opened this issue Feb 10, 2007 · 4 comments
Closed

bcwriter turns <2 x i10> into <2 x opaque> #1566

llvmbot opened this issue Feb 10, 2007 · 4 comments
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm:bitcode

Comments

@llvmbot
Copy link
Collaborator

llvmbot commented Feb 10, 2007

Bugzilla Link 1194
Resolution FIXED
Resolved on Feb 22, 2010 12:47
Version trunk
OS All
Reporter LLVM Bugzilla Contributor

Extended Description

Causes this test case to fail: test/Integer/packed_bt.ll

with this stack trace:

3 0x005c4859 in __assert_fail () from /lib/libc.so.6
#​4 0x081d9c39 in PackedType (this=0x9e3fe70, ElType=0x9e3fed0, NumEl=2) at
Type.cpp:429
#​5 0x081dcd53 in llvm::PackedType::get (ElementType=0x9e3fed0, NumElements=2)
at Type.cpp:1165
#​6 0x0815a10a in llvm::BytecodeReader::ParseType (this=0x9e3f788) at
Reader.cpp:1019
#​7 0x0815a417 in llvm::BytecodeReader::ParseTypes (this=0x9e3f788,
Tab=@0x9e3f84c, NumEntries=12) at Reader.cpp:1091
#​8 0x0815a537 in llvm::BytecodeReader::ParseGlobalTypes (this=0x9e3f788) at
Reader.cpp:1668
#​9 0x0815aa0d in llvm::BytecodeReader::ParseModule (this=0x9e3f788) at
Reader.cpp:1923
#​10 0x0815b3c2 in llvm::BytecodeReader::ParseBytecode (this=0x9e3f788,
Buf=0x9e3f910 "llvm\001", Length=178, ModuleID=@0xbff89814,
Decompressor=0x820a54e <llvm::Compressor::decompressToNewBuffer(char const*,
unsigned int, char*&, std::string*)>, ErrMsg=0xbff89918)
at Reader.cpp:2078
#​11 0x0814d5a6 in (anonymous namespace)::BytecodeStdinReader::read
(this=0x9e3f788, ErrMsg=0xbff89918) at ReaderWrappers.cpp:185
#​12 0x0814d6ce in llvm::getBytecodeModuleProvider (Filename=@0x82554fc,
BCDC=0x820a54e <llvm::Compressor::decompressToNewBuffer(char const*,
unsigned int, char*&, std::string*)>, ErrMsg=0xbff89918, H=0x0)
at ReaderWrappers.cpp:241
#​13 0x0814d711 in llvm::ParseBytecodeFile (Filename=@0x82554fc,
BCDC=0x820a54e <llvm::Compressor::decompressToNewBuffer(char const*,
unsigned int, char*&, std::string*)>, ErrMsg=0xbff89918)
at ReaderWrappers.cpp:251
#​14 0x0814a9e5 in main (argc=1, argv=0xbff89c14) at llvm-dis.cpp:57
@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 10, 2007

This seems to have something to do with the recent Type.cpp change that
eliminated unique types for the builtin integer types.

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 10, 2007

This had to do with a combination of things:

  1. IntegerType is no longer "primitive"
  2. Not all IntegerType instances are inserted early.
  3. BCReader in some cases needs IntegerType sub-types to be inserted before
    (for example) a packed type uses it.
  4. Recent slot calculator changes caused non-standard IntegerType instances
    to get slot calculator slots higher than their users.

The above caused a type slot number arrangement that forced the IntegerType
sub-type of a PackedType to have a higher slot number than the PackedType.
Consequently, bcreader created an OpaqueType for the IntegerType and then tried
to instantiate a PackedType with that. The resulting assertion ensued.

The fix for this is to just make sure that we insert things in a sane order.
This patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070205/044290.html

looks at a type's sub-types and inserts any that cannot recurse back before the
main type is inserted. For example, this type: <2 x i10>* was previously
inserted like this:

#​9: opaque#10 *
#​10: <2 x opaque#11>
#​11: i10

Now, it is inserted like this:

#​9: i10
#​10: <2 x i10>
#​11: <2 x i10>*

@lattner
Copy link
Collaborator

lattner commented Feb 10, 2007

I'm reopening this, as Reid is reevaluating this approach.

-Chris

@llvmbot
Copy link
Collaborator Author

llvmbot commented Feb 15, 2007

The fix for this was to allow the PackedType constructor to allow opaque types
just like ArrayType does. The change to the slot calculator was reverted.

Problem resolved.

@llvmbot llvmbot transferred this issue from llvm/llvm-bugzilla-archive Dec 3, 2021
clementval pushed a commit to clementval/llvm-project that referenced this issue Apr 11, 2022
@vdonaldson
Functions with alternate entry points and contained subprograms (llvm…
bbfa5a7 
…#1566)

Map function results to mlir values before generating host routine
association tuples, which may include function results.
troelsbjerre pushed a commit to troelsbjerre/llvm-project that referenced this issue Jan 10, 2024
@fredriss
Merge pull request llvm#1566 from JDevlieghere/🍒/b6635b5b15cb1c160776…
31fa24a 
…493a982302a854df332e

[lldb] Add SBCommandInterpreterRunOptions to LLDB.h
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bugzilla Issues migrated from bugzilla compile-fail Use [accepts-invalid] and [rejects-valid] instead llvm:bitcode
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@lattner @llvmbot