This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Patch for PR 14635 (regression: nan not in C90)
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Henderson <rth at redhat dot com>, "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 18 Mar 2004 18:06:50 -0700 (MST)
- Subject: Re: Patch for PR 14635 (regression: nan not in C90)
On Thu, 18 Mar 2004, Richard Henderson wrote:
> On Fri, Mar 19, 2004 at 01:56:29AM +0000, Joseph S. Myers wrote:
> > It is a feature for __builtin_nan(whatever) to expand to a constant
> > expression, so __builtin_nanf can be used to define NAN, but a bug for
> > (a function call) nan(whatever) to do so.
>
> Ah yes. Agreed wrt further changes to support nan as a "normal" function.
Could explain this rationale a bit more? I agreed with your initial
preference that these should be marked as C99 for nan{,f,l} and GCC
builtins as nans{,f,l}, and the relevant documentation updated to reflect
that these functions are available as with any other C99 builtin, i.e.
the __builtin_nan form is always available.
Why is it an issue for nan(whatever) to expand to a constant at
compiler-time, any more than it is for sqrt(4.0) for example.
Sorry if I'm being dense,
Roger
--