AlexVlx added a comment. In D150746#4357443 <https://reviews.llvm.org/D150746#4357443>, @rjmccall wrote:
> It's well-formed as IR, just not semantically valid, right? As long as it's > not actually crashing in the verifier, please test as much as you reasonably > can that's correct, like that the constructor and destructor functions take > something in the right address space, and that calls to them pass a valid > VTT. And then yeah, when you pull a v-table out and try to assign it, that > much will be incorrect until your next fix, but that's okay. Apologies, should have clarified: it is not well-formed IR in that it bitcasts pointers in different address spaces (e.g. vtable or typeinfo initializers are incorrectly typed as global array of generic pointers), so it will crash the verifier - think this https://gcc.godbolt.org/z/shfobqMqY captures most (including the behaviour this patch addresses). We "get away" with this in AMDGPU because this is a seldom if ever exercised code path and, more importantly, because the bitwise representation of generic & global pointers is the same, so there are no actual runtime bugs. My intention was to fix each of the issues in separate, isolated patches, fill out this test with additional checks since it captures all the problematic cases, and re-enable it as part of the final patch. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D150746/new/ https://reviews.llvm.org/D150746 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
