This is the mail archive of the gcc-prs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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:
 
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]