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

[Chris Lattner]

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!

-Chris