-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
const_to_int of const_gep results in broken getelementptr call, const_gep segfaults with i64 indexes #213
Comments
Determined that it's the same upstream (perhaps just my misunderstanding of LLVM since I'm pretty new), so I've created: https://gitlab.com/taricorp/llvm-sys.rs/-/issues/10 |
Actually, reopening because if using values other than i32 is really invalid for GEP instructions, should the API should probably be restricted in inkwell? |
With assertions on, the i64 indexes for GEP fails with:
|
Thanks for looking into this. There's nothing we can do about this at compile-time, but I suppose we could panic or return an |
Just to confirm, after reading through LLVM source code:
The call to this results in a null being returned if the type isn't an i32 or vec of i32, which results in the misleading assertion above being thrown: Invalid GetElementPtrInst indices for type. The real issue is that struct indexes must be i32s presently as suspected above. I also tested with other int types and they all fail the same way. Because they're any constant values, not just literaly, we shouldn't just take a &[i32], but as you said, it could check that values are i32s. |
I've figured out one of my GEP issues, digging through LLVM source - sharing here for anyone else who comes across this.
They're actually the same. It's working as intended. It just simplified the constant expression. I still agree with the validation - checking that GEP indexes are i32s - at least if debug assertions are turned on, perhaps. |
Would you be interested in making this change? |
Sure - opened #214. |
Describe the Bug
I'm not sure if these are related or not. If not, I apologize for the two-for-one.
const_gep followed by const_to_int results in the gep getting butchered (wrong type and an index goes missing in this example). Also const_gep with i64 values segfaults.
To Reproduce
Run this. See comments in code for details.
Expected Behavior
The gep on variable b should be the same as a, just with the pointer operation as well.
Less important (to me): The program should not segfault, unless gep with i64 indexes is just invalid or something - might be my mistake. If so, maybe it should take a u32 slice reference instead for the indexes?
LLVM Version (please complete the following information):
Desktop (please complete the following information):
Additional Context
LLVM built from source.
In LLVM clone dir:
In the clone of inkwell that cargo pulled:
The text was updated successfully, but these errors were encountered: