This is the mail archive of the
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>
- Cc: "Joseph S. Myers" <jsm at polyomino dot org dot uk>, <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 18 Mar 2004 21:16:05 -0700 (MST)
- Subject: Re: Patch for PR 14635 (regression: nan not in C90)
On Thu, 18 Mar 2004, Richard Henderson wrote:
> float x = nanf("");
> should not compile, whereas
> float x = __builtin_nanf("");
> must, given the promises we've made to libc about __builtin_nanf("")
> being an appropriate definition of the NAN macro.
But this sounds like a front-end issue. As a (undocumented) GCC
extension, the middle-end allows initializers to contain function
calls that can be evaluated at compile-time. For example:
const double pi = 4*atan(1.0);
compiles without problems with the C compiler, as would __builtin_atan
and similarly for nan and __builtin_nan. Which allows them to be used
to define NAN.
What I think is missing is the -pedantic or -Wall diagnostic from the
front-end to indicate that such initializations aren't very portable.
This code should then check "called_as_builtin" to distinguish the
__builtin_foo form from the foo form. But as demonstrated above this
isn't limited, nan. Indeed, the same is true of expressions such as
0.0/0.0, which GCC can evaluate at compile-time, but aren't required
by the C/C++ standards to be compile time constants.