[LLVMdev] When is getelementptr on an unsized type legal? (type system rewrite regression)

Chris Lattner clattner at apple.com
Mon Jul 11 23:32:15 PDT 2011

On Jul 11, 2011, at 11:55 AM, Eli Friedman wrote:

> Consider the following test case:
> %struct.A = type opaque
> @g = external global [0 x %struct.A]
> declare void @foo(%struct.A*)
> define void @f() uwtable ssp align 64 {
>  %x = getelementptr [0 x %struct.A]* @g, i32 0, i32 0
>  call void @foo(%struct.A* %x)
>  ret void
> }
> Before the type system rewrite, we would accept this construct; now,
> we reject it.  (This leads to clang/opt crashing on certain
> testcases.)
> Note that this is the natural way to represent the following C++ code
> (which now crashes clang):
> struct A;
> extern A g[];
> void foo(A*);
> void f(void) {
>  foo(g);
> }
> The question is, is should we accept the given IR?  If so, what rule
> do we use to accept it?

I think we should reject it, it doesn't really make sense to support.

>  If not, do we care about upgrading 2.9
> bitcode files with this construct?

I think that they are fine to break, this is very corner case.

I'll fix this in clang, thanks for bringing it to my attention, and for the great testcase!


More information about the llvm-dev mailing list