llvm dev - Jul 2011 - [LLVMdev] When is getelementptr on an unsized type legal? (type system rewrite regression)

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?  If not, do we care about upgrading 2.9
bitcode files with this construct?

-Eli

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