[Clang] constant evaluation should reject reinterpret_casting arbitrary addresses

[philnik777]

Clang currently accepts

#define fold(x) (__builtin_constant_p(x) ? (x) : (x))
constexpr int* x = fold((int*)123);

It looks like this has been added for GCC compatibility over a decade ago. However, GCC rejects this since version 7: https://godbolt.org/z/qMoK83dfP. I don't see a good reason this should be accepted, especially since GCC has started rejecting it a long time ago by now.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Nikolas Klauser (philnik777)

Clang currently accepts ```c++ #define fold(x) (__builtin_constant_p(x) ? (x) : (x)) constexpr int* x = fold((int*)123); ```

It looks like this has been added for GCC compatibility over a decade ago. However, GCC rejects this since version 7: https://godbolt.org/z/qMoK83dfP. I don't see a good reason this should be accepted, especially since GCC has started rejecting it a long time ago by now.

[tbaederr]

CC @efriedma-quic @zygoloid for opinions.

[efriedma-quic]

What are you proposing to do here, exactly? We definitely still need some form of compile-time folding of reinterpret_cast for parity with gcc (for variables not marked constexpr).

If you're proposing to remove the special semantics of a ?: where the condition is a __builtin_constant_p, we'll need more information about what gcc did, exactly; did they completely remove the extension to allow additional forms of constant in a ?: operator, or is it just more restricted? Do we want to follow gcc here? Do we need a construct that intentionally suppresses the normal C++ rules in favor of allowing whatever we can constant fold?

[9inefold]

Personally I've used this for some constexpr string type conversions, and have seen it used for constexpr type erasure and an offsetof implementation. While it might be niche, it would be a shame to see it removed entirely.

Here is another example using absolute addresses. You can replicate this in some situations with __asm__ (".equ SYMBOL, 0xNNNNN"), but can't do exactly what is described.

[Tsche]

While I agree that the current special ?: spelling is rather odd, I don't see much point in removing the feature entirely just because GCC chose to do so. (btw do we know why they did?)

Maybe it'd be interesting to expose this functionality as its own builtin? This would allow aligning __builtin_constant_p more closely with GCC while keeping the feature.

Currently we define a macro __enable_constant_folding 4 times and a macro fold 6 times for this purpose. Maybe __builtin_constant_fold would be a good name? Is there a reason this uses conditional expression syntax that I'm missing?

[frederick-vs-ja]

Special handling for __builtin_constant_p in the ternary condition operator seems to be a Clang-specific extension. When fold(x) is changed to (x), GCC started to reject the example since 7 with the same error messages too. If I understood correctly, GCC has never performed such special handling.

[efriedma-quic]

clang's behavior was originally based on gcc: see 84f6dcf / https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377 . I'm not sure what's happened since, though. CC @pinskia

[pinskia]

What changed for the original testcase had nothing to do with __builtin_constant_p though.
Take:

constexpr int* x = ((int*)123);

This was accepted in GCC 6 but started to be rejected in GCC 7 (this was changed with https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60760 ).

Note the testcases from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38377#c0 are still accepted in GCC trunk.

I should mention this is also accepted in the GCC trunk which should show the behavior of how the extension works; only the side that is evaluated is checked:

int ff;

#define fold(x) (__builtin_constant_p(x) ? &ff : (x))
constexpr int* x = fold((int*)123);

[zygoloid]

It looks like GCC still constant-folds (int*)123 at least in some circumstances -- in GCC 7 it stopped doing so, but it looks like this was undone again in GCC 11:

// Accepted by GCC 6 and earlier,
// and by GCC 11 and later.
int arr[(int*)123 ? 1 : 2]

In any case, we have not historically intended for Clang to constant-fold in exactly the same cases that GCC does -- that's practically impossible given the nature of how, what, and when GCC constant folds -- and instead we just intend to be compatible with real code, permissive in our constant folding, and consistent -- we only have one set of constant folding rules, not situation-dependent rules. Given that GCC still constant-folds (int*)123 in some circumstances (and given that GCC reinstated that behavior in GCC 11, I'm guessing users depend on this), I think it's probably best for compatibility that Clang still constant-folds it -- also, this is what allows us to emit things like

int *p = (int*)123;

with a constant initializer rather than producing a dynamic initializer and hoping the optimizer can clean it up. And given that GCC still provides the bcp_call behavior, I think it's best for compatibility that Clang still does the same. It's not clear to me what, if anything, we should change here.

(As an aside, the bcp_call-as-the-first-operand-of-?: behavior is horrifying, and I really wish we had a path away from that. Maybe it'd make sense for both compilers to add a __builtin_fold builtin whose purpose is to try to constant-fold its operand irrespective of language rules?)

[pinskia]

// Accepted by GCC 6 and earlier,
// and by GCC 11 and later.
int arr[(int*)123 ? 1 : 2]

This stopped working in GCC 8 and then started working again in GCC 11. I am not even sure this was done on purpose either.

[zygoloid]

Ah right, somehow I missed that GCC 7 accepts that too.