infinitely recursive named struct types

Hi,

Looks like it is possible to create an infinitely recursive struct type, llvm-as accepts this:
%s = type { i32, i8, %s }

define %s @foo(%s* %a) {
    %y = load %s* %a
    ret %s %y
}

%s2 = type { i32, %s3}
%s3 = type { i8, %s2}

declare %s3 @foo2();

Similarly it is doable via the API: create a named struct, create elements where one refers directly to the
newly created struct (instead of pointer), and then setbody.

I can't see how such a type can be useful (I created it by accident, meant to use pointer-to struct,
not struct type directly), and in fact llvm-dis crashes on bitcodes with infinetely recursive struct types.

I'd suggest that such infinetely (mutually-)recursive struct types should be rejected on creation,
at least via an assert.

FWIW llvm-as itself crashes on this:
%s = type { i32, i8, %s }
define void @foo() {
    %x = alloca %s
    ret void
}

Best regards,
--Edwin

Hi,

Looks like it is possible to create an infinitely recursive struct type, llvm-as accepts this:
%s = type { i32, i8, %s }

This should be illegal, and should probably be caught by the verifier.

-Chris

Chris,

Looks like it is possible to create an infinitely recursive struct type, llvm-as accepts this:
%s = type { i32, i8, %s }

This should be illegal, and should probably be caught by the verifier.

I suppose Edwin would like llvm to check (and let failed) in type
constructing, earlier than verifier.
I guess, such a insane type building might cause in various point,
...to go in an infinite loop or stack overflow.

...Takumi

There is a balance between time and cost of what happens in asserts and the verifier. If it's fast and has good algorithmic complexity, I wouldn't object to it as an assert.

-Chris

Chris Lattner wrote:

Chris,

Looks like it is possible to create an infinitely recursive struct type, llvm-as accepts this:
%s = type { i32, i8, %s }

This should be illegal, and should probably be caught by the verifier.

I suppose Edwin would like llvm to check (and let failed) in type
constructing, earlier than verifier.

I would like the verifier to catch all problems even in a build with asserts disabled. Also adding an assert is a great idea though.

Nick