This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/79452] Provide builtin to detect compile-time execution


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79452

--- Comment #6 from gnzlbg <gonzalobg88 at gmail dot com> ---
> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]