This is the mail archive of the
mailing list for the GCC project.
pending/7834: Re: Test 18_support/numeric_limits.cc execution fails on cygwin
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 5 Sep 2002 09:26:08 -0000
- Subject: pending/7834: Re: Test 18_support/numeric_limits.cc execution fails on cygwin
- Reply-to: Gabriel Dos Reis <gdr at integrable-solutions dot net>
The following reply was made to PR pending/7834; it has been noted by GNATS.
From: Gabriel Dos Reis <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org
Subject: pending/7834: Re: Test 18_support/numeric_limits.cc execution fails on cygwin
Date: 05 Sep 2002 11:09:27 +0200
>Synopsis: Re: Test 18_support/numeric_limits.cc execution fails on cygwin
>Arrival-Date: Thu Sep 05 02:16:01 PDT 2002
| >Category: libstdc++
| >Synopsis: Test 18_support/numeric_limits.cc execution fails on cygwin
| >Confidential: no
| >Severity: serious
| >Priority: medium
| >Class: sw-bug
| >Submitter-Id: net
| >Originator: David Billinghurst
| >Release: gcc-3.3
| Test 18_support/numeric_limits.cc execution now fails on cygwin with
| assertion "extrema_min == limits_min" failed.
I gather this happens because of my recent changes in this area. And
happens for long double only for the following reasons:
1) the compiler reports that sizeof (long double) == 12
2) base on 1), V3 assumes the compiler uses the full 96 bits for
3) step 2) is wrong becase the compiler actually uses only 80 bits
which means that most values will be wrong.
RTH recently applied patches to the compiler + V3 so that the above
mentioned artefacts don't show up in user code.
| If I change the test to use the long double specialization that FreeBSD uses then the test passes, so things can't be too bad.
I suspect FreeBSD is using full 96 bits...
| I am unsure if this is best fix, but it may be good enough.
Well, with RTH's recent patches, things should return back in the
normal state. Can you confirm?