module verifier allows unsized types that crash llc / llvm-as accepts invalid .ll

[Quuxplusone]

Bugzilla Link	PR3283
Status	RESOLVED FIXED
Importance	P normal
Reported by	Török Edwin (edwin+bugs@etorok.eu)
Reported on	2009-01-06 05:20:53 -0800
Last modified on	2011-07-11 10:24:34 -0700
Version	unspecified
Hardware	PC Linux
CC	clattner@nondot.org, evan.cheng@apple.com, llvm-bugs@lists.llvm.org, llvm@sunfishcode.online, nicholas@mxc.ca
Fixed by commit(s)
Attachments	unsized.tar.gz (1253 bytes, application/octet-stream)
Blocks
Blocked by
See also

With SVN r61805 I run:
$ llvm-as <tst.ll >x.bc && llc x.bc -f

I get this:

llc: TargetData.cpp:468: unsigned char llvm::TargetData::getAlignment(const
llvm::Type*, bool) const: Assertion `Ty->isSized() && "
Cannot getTypeInfo() on a type that is unsized!"' failed.
0   llc       0x0000000000c2dd1f
1   libc.so.6 0x00007fd7d0afcf60
2   libc.so.6 0x00007fd7d0afced5 gsignal + 53
3   libc.so.6 0x00007fd7d0afe3f3 abort + 387
4   libc.so.6 0x00007fd7d0af5dc9 __assert_fail + 233
5   llc       0x0000000000b5ee5e llvm::TargetData::getAlignment(llvm::Type
const*, bool) const + 222
6   llc       0x0000000000718e76
7   llc       0x000000000071a4d9
8   llc       0x0000000000bc2ff6 llvm::FunctionPassManager::doFinalization() +
198
9   llc       0x0000000000500618 main + 4216
10  libc.so.6 0x00007fd7d0ae91a6 __libc_start_main + 230
11  llc       0x00000000004feae9 std::ios_base::Init::~Init() + 57
Aborted

This is either a bug in llvm-as (for accepting invalid bitcode), or a bug in
llc, this is the .ll file:
hidden thread_local addrspace(39) constant opaque undef

[Quuxplusone]

Attached unsized.tar.gz (1253 bytes, application/octet-stream): more .ll files

[Quuxplusone]

Polygen strikes again! (I assume :-))

[Quuxplusone]

This sort of thing happens because llc can't handle all 'valid' .ll files.

This is a result of a somewhat nice but admittedly questionable design decision: we allow some types that "should" be concrete for a program to make sense to be abstract. This allows someone to later define the type (e.g. by llvm-link'ing in another .bc file) allowing some interesting separation of concerns.

I think we should close this as behaves correctly, because I don't think we want to give this up. It would be nice for llc to generate a better error message though. What do you think?

[Quuxplusone]

A specific use case is listed here:
http://nondot.org/sabre/LLVMNotes/MSILObjectModel1.txt

Search for 'opaque'.

[Quuxplusone]

Fixed by the type system rewrite.