I think this is pretty uncommon so I was trying to implement it without adding new opcodes, but looks like that's not possible.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/AST/Interp/Opcodes.td | ||
---|---|---|
402–406 | Don't both of these result in a Pointer? And should they have a Types field? | |
clang/test/AST/Interp/arrays.cpp | ||
245–331 | I'd like test cases where the pointer arithmetic has run off the beginning/end of the object (forming the invalid pointer is UB per http://eel.is/c++draft/expr.add#4.3 even if you never dereference the pointer). |
clang/lib/AST/Interp/Opcodes.td | ||
---|---|---|
402–406 | Ah yes, they do. They don't need a type field, we know we're operating on a pointer. |
clang/test/AST/Interp/arrays.cpp | ||
---|---|---|
245–331 | constexpr int bad1() { const int *e = E + 3; e++; // This is fine because it's a one-past-the-end pointer return *e; // This is UB } constexpr int bad2() { const int *e = E + 4; e++; // This is UB return *e; // This is UB as well } constexpr int bad3() { const int *e = E; --e; // This is UB return *e; // This is UB as well } |
clang/test/AST/Interp/arrays.cpp | ||
---|---|---|
245–331 | Interesting side-effect of removing the Run call in isPotentialConstantExpression(): The new constant interpreter doesn't diagnose the "never produces a constant expression` case. The function must be called for any diagnostics to be printed. |
Don't both of these result in a Pointer? And should they have a Types field?