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 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.

Roger
--


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