This is the mail archive of the
mailing list for the GCC project.
Re: PATCH c++/19628 (take 2)
On Jan 30, 2005, at 2:37 PM, Gabriel Dos Reis wrote:
"Joseph S. Myers" <firstname.lastname@example.org> writes:
| On Sun, 30 Jan 2005, Roger Sayle wrote:
| > One distinction that may be useful in this respect, might be
| > 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
| case of nan*, only where they have string constant arguments).
| 1) These all only exist in the __builtin_ form, although it would
| possible for the nan functions to become C99_BUILTIN instead of
| GCC_BUILTIN since you fixed the bug that would have allowed calls to
| "nan" as constant.
| 2) These can only be used in arithmetic constant expressions, not
| constant expressions, but whether something is or is not an
| 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.
I agree. I know the proposal you're talking about. It's much broader
than my patch, and, while I haven't thought all that much about
implementing it, I'm pretty sure it would take some serious
restructuring in the C++ front end. I think it's mostly orthogonal to