This is the mail archive of the gcc-patches@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]

Re: PATCH c++/19628 (take 2)


On Jan 30, 2005, at 2:37 PM, Gabriel Dos Reis wrote:

"Joseph S. Myers" <joseph@codesourcery.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
constant expressions.
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 my patch.


--Matt



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