Re: pending/7834: Re: Test 18_support/numeric_limits.cc execution fails on cygwin

Re: pending/7834: Re: Test 18_support/numeric_limits.cc execution fails on cygwin

[neil]

Synopsis: Re: Test 18_support/numeric_limits.cc execution fails on cygwin

State-Changed-From-To: open->closed
State-Changed-By: neil
State-Changed-When: Sat Sep 14 02:31:20 2002
State-Changed-Why:
    Not a PR.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7834

pending/7834: Re: Test 18_support/numeric_limits.cc execution fails on cygwin

[Gabriel Dos Reis]

The following reply was made to PR pending/7834; it has been noted by GNATS.

From: Gabriel Dos Reis <gdr@integrable-solutions.net>
To: gcc-bugs@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: pending/7834: Re: Test 18_support/numeric_limits.cc execution fails on cygwin
Date: 05 Sep 2002 11:09:27 +0200

 >Number:         7834
 >Category:       pending
 >Synopsis:       Re: Test 18_support/numeric_limits.cc execution fails on cygwin
 >Confidential:   yes
 >Severity:       serious
 >Priority:       medium
 >Responsible:    unassigned
 >State:          open
 >Class:          sw-bug
 >Submitter-Id:   net
 >Arrival-Date:   Thu Sep 05 02:16:01 PDT 2002
 >Closed-Date:
 >Last-Modified:
 >Originator:     
 >Release:        
 >Organization:
 >Environment:
 >Description:
  David.Billinghurst@riotinto.com writes:
  
  | >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
  | >Environment:
  | i686-pc-cygwin
  | >Description:
  | 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
       storing double.
    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?
  
  -- Gaby
 >How-To-Repeat:
 >Fix:
 >Release-Note:
 >Audit-Trail:
 >Unformatted: