Re: V3 PATCH: numeric_limits<> support, fix PR/3865

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Hi,

  [ Sorry for replying so late, I've gotten busy by some issues here ]

Richard Henderson <rth@redhat.com> writes:

| On Sun, Sep 01, 2002 at 12:49:32PM +0200, Gabriel Dos Reis wrote:
| > That makes the assumption that IEEE-exception for division by zero is
| > disabled.  Something I can't control.  Instead, we should just produce
| > the right thing in the compiler, as a builtin.
| 
| In C, I'd be relying on the fact that this initialization *cannot*
| happen at runtime, and thus must be constant folded by the compiler.

Well, the exact C++ words are:
3.6.2/1

  The storage for objects with static storage duration (3.7.1) shall
  be zero-initialized (8.5) before any other initialization takes
  place. Zero-initialization and initialization with a constant
  expression are collectively called static initialization; all other
  initialization is dynamic initialization. Objects of POD types (3.9)
  with static storage duration initialized with constant expressions
  (5.19) shall be initialized before any dynamic initialization takes
  place. Objects with static storage duration defined in namespace
  scope in the same translation unit and dynamically initialized shall
  be initialized in the order in which their definition appears in the
  translation unit. 

What happens for 1.0f/0.0f on systems that do not have infinity?  Does
GCC always fold constants? (I'm asking because I don;t know whether it
does that only at some optimizations levels).

| With G++, at present, I believe this would always be done at compile
| time as well.  What sort of verbage does ISO C++ have regarding this?
| 
| (Testing this with 3.2,
| 
| 	extern "C" int printf(const char *, ...);
| 
| 	struct S
| 	{
| 	  static const float inf = 1.0f / 0.0f;
| 	  static const float nan = 0.0f / 0.0f;
| 	};

In C++, this would be written slighly differently:

   struct S 
   {
     static const float inf = 1.0f / 0.0f;
     static const float nan = 0.0f / 0.0f;
   };

   // in a .cc file
   const float S::inf = 1.0f / 0.0f;
   const float S::nan = 0.0f / 0.0f;

[...]

| we get two screwy warnings
| 
| 	z.cc:5: warning: division by zero in `
| 	   0x00000000000000000080ff3f0000000000000000 / 0.'
| 	z.cc:6: warning: division by zero in `
| 	   0x0000000000000000000000000000000000000000 / 0.'

Yes, from time to time I find them very annoying, especially in the
form they're printed.
While back, I fixed the printing with

   2001-09-15  Gabriel Dos Reis  <gdr@merlin.codesourcery.com>

	   * Make-lang.in (cp/error.o): Depend on real.h
	   * error.c: #include "real.h"

but a patch from Zack

   2002-03-22  Zack Weinberg  <zack@codesourcery.com>

	   * error.c: Always use REAL_VALUE_TO_DECIMAL; don't test
	   REAL_IS_NOT_DOUBLE.

reverted the fix.  I don't know why he did that.  Zack?

| Not sure why we're warning here (C doesn't), but if the warning
| is retained, we should fix the printing of the fp constant.
| However, the constant folding happens exactly as expected; 
| indeed is correctly substituted into the code directly
| 
|         movl    $.LC0, (%esp)
|         movl    $0, 4(%esp)
|         movl    $2146435072, 8(%esp)
|         movl    $0, 12(%esp)
|         movl    $2146959360, 16(%esp)
| 	call	printf

Good.  Does the compiler does that no matter how the optimization
level is?

[...]

| > I like your design better.  Can we agree on implementing that for 3.4
| > rather than 3.3?
| 
| I'm not fond of having these macros become permanent.  Please
| document all of them as gcc internal and that they may well be
| removed in the next release.

OK, will do that in a coming patch.

| Alternately, what if I were to do the backend work?  I'd be
| fixing our current float.h inconsistencies (suitable for stage3).

That is fine by me.  I just have to point out that C and C++ don't
follow the same standards: while C seems to promote its own modified
version of IEEE-754, C++ follows LIA-1.  The immediate consequence is
that we have to define consistent numeric_limits<> that reflect the
implementation characteristics on all the supported plateform, not
just on IEEE-754 plateforms.  For a system that do not have IEEE-754
signed zero, what should we do in C++?  Follow C99 dispositions that
are targetting its insistance on IEEE-754?

| The addition of __builtin_nan could be considered part of the
| fix for the bug you're working on.  At which point it ought to
| be only a couple lines change in libstdc++...

Great! I vote for it.  Is there anything I can do (apart from changing
the two lines)?

Thanks,

-- Gaby