This is the mail archive of the 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 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 
initializers can be non-constant and there's flexibility in the 
initialization order rules to allow such initializers with constant value 
to be treated as constant even when not actually constant expressions. 
(Whereas __builtin_constant_p is by design usable in integer constant 

Joseph S. Myers      (personal mail) (CodeSourcery mail) (Bugzilla assignments and CCs)

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