[LLVMdev] nested GEP in a static initializer fails
Nick Lewycky
nicholas at mxc.ca
Tue Oct 26 00:12:03 PDT 2010
Joel E. Denny wrote:
> Hi,
>
> Given this LLVM assembly:
>
> @a = global i8* getelementptr (i8* null, i64 mul (i64 ptrtoint (i32* getelementptr (i32* null, i32 1) to i64), i64 2))
>
> llc fails an assertion:
>
> llc: /home/jdenny/llvm-svn/include/llvm/Support/Casting.h:202: typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X = llvm::ConstantInt, Y = llvm::Value*]: Assertion `isa<X>(Val)&& "cast<Ty>() argument of incompatible type!"' failed.
>
> This has been reported previously as a bug and was resolved as invalid:
>
> http://llvm.org/bugs/show_bug.cgi?id=2672
>
> The explanation was:
>
> "I don't think we should try to fold arbitrary expressions in the code
> generator. Instead, we should accept that targets have limitations on
> these. We can't ever support things like "void *X =&G /&H;" for
> example."
>
> Are the limitations on what can be placed in a static initializer
> documented somewhere?
No.
When those limitations aren't obeyed, would it be
> possible for llc to print a more intelligible error message for the user?
The limitations are a product of the ABI and on-disk .o file format. For
example, given "int X = (int)&G / (int)&H;", llc will happily generate
"X: .long G/H" which is invalid assembly, but llc doesn't know that.
Maybe with the MC infrastructure we could start to figure out what is
and isn't representable. That would be nice since the frontend may need
to change its behaviour, for example, GCC lowers the example code into a
C++ static initializer function to calculate the value for X at load
time before main() starts. As of today, llvm-gcc and clang both get this
wrong.
Nick
More information about the llvm-dev
mailing list