Re: 3.0.1 Freeze

[Mark Mitchell <mark at codesourcery dot com>]

--On Monday, August 06, 2001 09:37:42 PM -0400 David Edelsohn 
<dje@watson.ibm.com> wrote:

> Mark,
>
> 	Is your proposal to define all of the values now extracted from
> the system limits.h and float.h, e.g., LONG_MAX?

Sort of; let me try to make this clearer below.

> My patch already
> corrected the digits values for normal targets.  You can get the normal
> values for INT_MAX and LONG_MAX for 32-bit and 64-bit targets from any
> standard system.
>
> 	limits_generic.h is a perfectly good starting point.

I'm sure that's true, and it's fine to work from that instead.  There
are probably five ways to solve this problem in basically the same way,
and none of them is more than a good day's effort.  It is more important
to pick one -- any one -- than to worry about it too much.  So, yes,
let's try to adapt limits_generic.h for this purpose.

>
> 	The real work seems to be not defining __glibcpp_int_bits, etc.,
> but determining the appropriate macro(s) to test in the OS configs for
> sizes that change in different multilibs.  Many can be found in
> gcc/glimits.h or in the definition of the CPP_SPEC macro for each target.

Right, that is another part of the work.  Would you like to help go
through and start doing that?  At least for RS6000 to start, as a model
for others?  That's a good way to divide up the work; Gaby/I can work
on the generic stuff, you/others can work on the ports.  The interface
is the series of __glibcpp_int_bits, __glibcpp_float_bits, etc.

Let's agree that a OS/CPU configuration file needs to specify these
only if they are different from a "standard 32-bit system".  On such
a system:

  #define __glibcpp_char_bits 8
  #define __glibcpp_plain_char_is_signed true
  #define __glibcpp_short_bits 16
  #define __glibcpp_int_bits 32
  #define __glibcpp_long_bits 32
  #define __glibcpp_wchar_t_bits 32
  #define __glibcpp_long_long_bits 64
  #define __glibcpp_float_bits 32
  #define __glibcpp_double_bits 64
  #define __glibcpp_long_double_bits 128

So, if a system matches this, it doesn't need to do anything.  If
any of the values are different, it needs to define those values
that are different.  Would you care to coordinate with people to get
these values defined in the various configuration files, which will,
as you say, requiring testing some macros on multilibbed systems?

An alternative would be to have the preprocessor define these macros
rather than putting them in the config headers.  It is even possible that 
the preprocessor could automatically define them based on the machine .h 
files in the GCC core -- but I don't want us in those bits at this point.
Let's do it by hand now; we can come back and do something more automated
on the mainline.  The goal is touch only things in V3 to avoid risk to
C, Fortran, and Java.

There are also the bits about rounding modes and denormals and such;
those need to be defined in the os configuration file as well.  But,
we can leave those for now; let's get the basics up and running.  (And,
it looks like gen-num-limits sets many of those values without testing
anything anyhow.)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com