This is the mail archive of the
mailing list for the GCC project.
Re: PATCH c++/19628 (take 2)
"Joseph S. Myers" <email@example.com> writes:
| On Sun, 30 Jan 2005, Roger Sayle wrote:
| > One distinction that may be useful in this respect, might be something
| > like builtin.c's CALLED_AS_BUILT_IN macro. This can be used to
| > distinguish built-in functions called as __builtin_foo from those
| > called as foo (or std::foo). By using this, the C++ front-end
| > maintainers could choose to allow __builtin_fabs(0.0) to be a
| > compile-time constant, whilst retaining the usual semantics of
| > fabs(0.0). __builtin_constant_p would then be just a special case.
| The __builtin_nan*, __builtin_inf* and __builtin_huge_val* built-in
| functions are documented as being usable in constant expressions (in the
| case of nan*, only where they have string constant arguments). However:
| 1) These all only exist in the __builtin_ form, although it would now be
| possible for the nan functions to become C99_BUILTIN instead of
| GCC_BUILTIN since you fixed the bug that would have allowed calls to plain
| "nan" as constant.
| 2) These can only be used in arithmetic constant expressions, not integer
| constant expressions, but whether something is or is not an arithmetic
| constant expression is not particularly important in C++ since static
except when used as template arguments.
There is some consensus and a proposal to allow "sufficiently simple"
functions (a.k.a. "constant-valued functions") to be considered as
While Matt's patch is a step in that direction, I think we should
consider constant-valued functions independently of this patch.