target/6540: sparc-sun-solaris2.7 (perhaps all bi-arch sparc) fail libstdc++-v3 18_support/numeric_limits.cc

[ghazi@caip.rutgers.edu]

>Number:         6540
>Category:       target
>Synopsis:       sparc-sun-solaris2.7 (perhaps all bi-arch sparc) fail libstdc++-v3 18_support/numeric_limits.cc
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 02 09:06:00 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Kaveh Ghazi
>Release:        gcc version 3.1 20020501 (prerelease)
>Organization:
>Environment:
sparc-sun-solaris2.7 native as/ld
>Description:
The libstdc++-v3 test 18_support/numeric_limits.cc fails on sparc-sun-solaris2.7 for -m32 but succeeds for -m64 as seen here:
http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00028.html
http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00048.html
It passes on sparcv9:
http://gcc.gnu.org/ml/gcc-testresults/2002-05/msg00003.html

On my solaris2.7 system, it fails on the long double test_extrema.  I tracked this down to the definition of LDBL_MIN/LDBL_MAX from gcc/config/float-sparc.h.  In there, we define a 128 bit LDBL_* only if sparcv9 or arch64 are defined.  However sol2-bi.h hardcodes LONG_DOUBLE_TYPE_SIZE to 128.

So this is really a bug in the float.h that gets generated for solaris2.7.  Using this program to demonstrate:

#include <stdio.h>
#include <float.h>
int main()
{
  long double min = LDBL_MIN, max = LDBL_MAX;
  printf ("%d\n%Le\n%Le\n", (int) sizeof(long double), min, max);
  return 0;
}

If I compile with -m32, I get:
16
2.225074e-308
1.797693e+308

If I compile with -m64, I get:
16
3.362103e-4932
1.189731e+4932

IMHO, I should get the latter result for both cases.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: