[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 --- Comment #12 from Jonathan Wakely --- Well this request is satisfied by std::is_constant_evaluated() in C++20, which is what __builtin_is_constant_evaluated() exists for. PR 100974 adds a newer C++23 language feature that makes std::is_constant_evaluated() unnecessary. This is still resolved one easy or another though.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #11 from Andrew Pinski --- This is done for C++23 but GCC implements __builtin_is_constant_evaluated also for old C++ standards. Anyways this is a dup of bug 100974. *** This bug has been marked as a duplicate of bug 100974 ***
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #10 from Markus Trippelsdorf --- Also see Daveed's proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0595r0.html
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 --- Comment #9 from Eric Fiselier --- I think it would be nice to be able to dispatch differently depending on being called at compile time or runtime. However the ability to dispatch on that condition doesn't have to be usable in "if constexpr". That way we don't run into any instantiation problems. If that behavior is desireable enough I think it could be simply implemented as an invented __ctfe__ function local variable that changes value.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 --- Comment #8 from gnzlbg --- Eric your concerns and suggestions make sense. Changing the signature of the functions using something like __ctfe__ and probably anything that would use those sounds like a major ABI breaking change though. I do not think we can find a better solution though, but it makes me reconsider whether we really need this. We do need something like this, but i don't know at what cost.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
Eric Fiselier changed:
What|Removed |Added
CC||eric at efcs dot ca
--- Comment #7 from Eric Fiselier ---
There are definitely opportunities for ODR violations here, or at least
something like them. Consider the following case:
template
constexpr bool foo(T) {
if constexpr(__ctfe__)
return true;
else
return false
}
static_assert(foo(0));
auto runtime = foo(0);
Both calls instantiate foo with the same template arguments, so they should
seemingly both get the same instantiation with the w/e value of `__ctfe__` was
when the implicit instantiations occurred. Therefore one of the two calls to
foo() will return the wrong answer.
This problem is made ever worse if `__builtin_constant_expression` allows you
to generate non-dependent compile-time expressions based on the function
arguments.
One solution would be to consider the instantiation of `foo` to be value
dependent on a "implicit template parameter" representing `__ctfe__`.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 --- Comment #6 from gnzlbg --- > I wasn't replying to the part about function aliases, I was replying to the > part about having the built-in work even when used in a non-constexpr > function. It sounds like what you're suggesting would depend on optimisation > levels, rather than on the unambiguous semantics of whether something is > actually a constant-expression or not as defined by the C++ language. Maybe I > misunderstood what you mean by "some block inside that function is evaluated > by the constant expression evaluator". I actually meant that, but yes, you are 100% correct, that would definetely lead to ODR issues. Thanks for pointing this out, I guess that the builtin should, as you say, only be usable in constant expressions (as defined by C++). > What about __builtin_constant_expression. FWIW I went with __ctfe for the built-in because there is prior-art in D. It has a built-in named __ctfe (compile-time function evaluation) that does what is being proposed here, see: http://dlang.org/spec/function.html The only important thing is that the built-in does not resemble anything that we might ever want to standardize to avoid collisions. I would rather wait for an agreement on the semantics before bike-shedding the name, but: - __ctfe - __builtin_constant_expression - reciclying __builtin_constant_p() without any expression, __builtin_constant_p(expr) already exists in gcc and detects whether expr returns a value known at compile-time. There are multiple candidates, I actually don't really care much for the name as long as it is sufficiently self explanatory. I'd rather decide which approach is worth pursuing, and which semantics should the builtin have, so that somebody can submit a patch with chances of getting merged. We can always bike-shed the name of the builtin or attribute at the last minute and just change it.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 --- Comment #5 from Andrew Pinski --- What about __builtin_constant_expression.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
--- Comment #4 from Jonathan Wakely ---
(In reply to gnzlbg from comment #2)
> if constexpr() { // Error: expression missing in if condition
Oh, I didn't realise you meant without an expression. Yeah that doesn't work.
> > That sounds like a recipe for ODR violations.
>
> Could you elaborate on why? Since the `constexpr_alias` will only be called
> during compile-time evaluation, it will never collide with the "run-time"
> alias (which is inline, since constexpr implies inline). Note that
> `foo_constexpr` is a completely different function than `foo`, so these two
> never collide either.
I wasn't replying to the part about function aliases, I was replying to the
part about having the built-in work even when used in a non-constexpr function.
It sounds like what you're suggesting would depend on optimisation levels,
rather than on the unambiguous semantics of whether something is actually a
constant-expression or not as defined by the C++ language. Maybe I
misunderstood what you mean by "some block inside that function is evaluated by
the constant expression evaluator". If you simply mean when the built-in
appears as part of a constant-expression that's fine.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 --- Comment #3 from gnzlbg --- I guess I should have written, "How does this feature make ODR violations more common than the inline keyword?". Which new perils does it introduce?
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
--- Comment #2 from gnzlbg ---
> It's already in C++17 and supported by GCC.
The following program is ill-formed in C++17:
int main() {
if constexpr() { // Error: expression missing in if condition
return 1;
}
return 0;
}
> That sounds like a recipe for ODR violations.
Could you elaborate on why? Since the `constexpr_alias` will only be called
during compile-time evaluation, it will never collide with the "run-time" alias
(which is inline, since constexpr implies inline). Note that `foo_constexpr` is
a completely different function than `foo`, so these two never collide either.
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/79452] Provide builtin to detect compile-time execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452
--- Comment #1 from Jonathan Wakely ---
(In reply to gnzlbg from comment #0)
> Implementation as a builtin is preferred, because it is possible that "if
> constexpr() { }" syntax will be proposed for standardization.
It's already in C++17 and supported by GCC.
> I'd rather have this built-in always work. That is, even if its invoked
> inside a non-constexpr function, it might still be that some block inside
> that function is evaluated by the constant expression evaluator of the C++
> compiler. The built-in should detect this case properly.
That sounds like a recipe for ODR violations.
