This is the mail archive of the 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]

libstdc++/6553: 26_numerics/ fails in Tru64 UNIX V5.1

>Number:         6553
>Category:       libstdc++
>Synopsis:       26_numerics/ fails in Tru64 UNIX V5.1
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Fri May 03 14:26:00 PDT 2002
>Originator:     Rainer Orth
>Release:        3.1 20020426 (prerelease)
Faculty of Technology, Bielefeld University
System: OSF1 bartok V5.1 732 alpha
Machine: alpha
host: alpha-dec-osf5.1
build: alpha-dec-osf5.1
target: alpha-dec-osf5.1
configured with: /vol/gnu/src/gcc/gcc-3.1-branch-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls alpha-dec-osf5.1
Comparing testresults for Tru64 UNIX V4.0F

and V5.1

there's only a single difference: an additional failure in V5.1:

FAIL: 26_numerics/ execution test.  In libstdc++.log,
I find

Assertion failed: flteq(z.imag(), y), file /amnt/zacatecas/volumes/d9/gnu/src/gcc/gcc-3.1-branch-dist/libstdc++-v3/testsuite/26_numerics/, line 48

This is 

	VERIFY( flteq(z.imag(), y) );

the first long double invocation of test_good() with "(-1.1,3.7)#" as input
string, as can be seen in a stacktrace:

#6  0x12001c9a8 in _Z9test_goodIeEiSsT_S0_ (str={
      static npos = <incomplete type>, 
      _M_dataplus = {<allocator<char>> = {<No data fields>}, 
        _M_p = 0x14000c818 "(-1.1,3.7)#"}, static _S_empty_rep_storage = {0, 
        0, 0, 0}}, x=-1.1000000000000000888178419700125232, 
    at /vol/gnu/src/gcc/gcc-3.1-branch-dist/libstdc++-v3/testsuite/26_numerics/
#7  0x120019304 in _Z7testallIeEiv ()
    at /vol/gnu/src/gcc/gcc-3.1-branch-dist/libstdc++-v3/testsuite/26_numerics/
#8  0x12000e9cc in main ()
    at /vol/gnu/src/gcc/gcc-3.1-branch-dist/libstdc++-v3/testsuite/26_numerics/
139  testall<long double>();

Unfortunately, print z in gdb 5.2 just yields

$2 = {_M_value = Invalid C/C++ type code 20 in symbol table.

so I cannot easily debug this further.

Since this is a long double test failing and a primary difference between
V4.0F and V5.1 is the support for 128-bit long double, this might well be
related to problems with long double argument passing.
Bootstrap compiler and run testsuite.

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