[Bug c/48341] New: LDBL_EPSILON is wrong on IRIX 6.5

[Bug c/48341] New: LDBL_EPSILON is wrong on IRIX 6.5

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

           Summary: LDBL_EPSILON is wrong on IRIX 6.5
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ro@gcc.gnu.org
              Host: mips-sgi-irix6.5
            Target: mips-sgi-irix6.5
             Build: mips-sgi-irix6.5


When looking at a libstdc++ testsuite failure on IRIX 6.5

FAIL: 18_support/numeric_limits/epsilon.cc execution test

Assertion failed: EX, file
/vol/gcc/src/hg/gcc-4.6-branch/local/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon.cc,
line 37

I found that the testcase aborts checking long double LDBL_EPSILON:

Program received signal SIGABRT, Aborted.
0x0fa4ac28 in _prctl () from /usr/lib32/libc.so.1
(gdb) where
[...]
#5  0x0fa756c4 in __assert () at
/xlv86/patches/7207/work/irix/lib/libc/libc_n32_M4/gen/assert.c:59
#6  0x10002210 in test_epsilon<long double> () at
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon.cc:37
#7  0x10002108 in main () at
/vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/18_support/numeric_limits/epsilon.cc:44

While epsilon is printed as 0 here, in
mips-sgi-irix6.5/libstdc++-v3/include/limits, I find __LDBL_EPSILON__ is
-1.596672247627775849325098170429471e+293

Running the testcase through g++ -g3 -save-temps, epsilon.ii reveals

#define __FLT_EPSILON__ 1.19209289550781250000000000000000e-7F
#define __DBL_EPSILON__ double(2.22044604925031308084726333618164e-16L)
#define __LDBL_EPSILON__ 4.94065645841246544176568792868221e-324L

which is obviously bogus.  The native <internal/float_core.h> has

#define FLT_EPSILON     1.19209290E-07F
#define DBL_EPSILON     2.2204460492503131E-16
#define LDBL_EPSILON    1.232595164407830945955825883254353E-32L

IRIX 6 uses the IBM double format for long double.  As expected, the
gcc.target/powerpc/rs6000-ldouble-2.c testcase also FAILs.

eps is correctly determined:

(gdb) p eps
$1 = 2.465190328815661891911651766508707e-32

This can be seen with the following test:

$ cat ld.c
#include <stdio.h>
#include <float.h>

int
main (void)
{
  printf ("LDBL_EPSILON = %Lg\n", LDBL_EPSILON);
  return 0;
}
$ cc -o ld-cc ld.c
$ ./ld-cc 
LDBL_EPSILON = 1.2326e-32
$ ./xgcc -B./ -o ld-gcc ld.c
$ ./ld-gcc 
LDBL_EPSILON = 4.94066e-324

[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-03-29 18:50:47 UTC ---
On Tue, 29 Mar 2011, ro at gcc dot gnu.org wrote:

> Running the testcase through g++ -g3 -save-temps, epsilon.ii reveals
> 
> #define __FLT_EPSILON__ 1.19209289550781250000000000000000e-7F
> #define __DBL_EPSILON__ double(2.22044604925031308084726333618164e-16L)
> #define __LDBL_EPSILON__ 4.94065645841246544176568792868221e-324L
> 
> which is obviously bogus.  The native <internal/float_core.h> has

Why do you think this is bogus?  It's correct for IBM long double, where 
the mantissa bits can be discontiguous, and so the least value greater 
than 1 that is representable has such discontiguous bits.  See PR 19405 
and <http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00374.html>.

[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-03-30 15:16:57 UTC ---
> Why do you think this is bogus?  It's correct for IBM long double, where 
> the mantissa bits can be discontiguous, and so the least value greater 
> than 1 that is representable has such discontiguous bits.  See PR 19405 
> and <http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00374.html>.

But why do both that exact testcase and the libstdc++ one fail with this
LDFL_EPSILON value on IRIX, and disagree with both the one from the
system headers, which is identical to the one found in the
gcc.target/powerpc/rs6000-ldouble-2.c test?

    Rainer

[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-03-30 15:43:53 UTC ---
On Wed, 30 Mar 2011, ro at CeBiTec dot Uni-Bielefeld.DE wrote:

> --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2011-03-30 15:16:57 UTC ---
> > Why do you think this is bogus?  It's correct for IBM long double, where 
> > the mantissa bits can be discontiguous, and so the least value greater 
> > than 1 that is representable has such discontiguous bits.  See PR 19405 
> > and <http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00374.html>.
> 
> But why do both that exact testcase and the libstdc++ one fail with this
> LDFL_EPSILON value on IRIX, and disagree with both the one from the
> system headers, which is identical to the one found in the
> gcc.target/powerpc/rs6000-ldouble-2.c test?

Presumably the implementation of long double arithmetic being used on IRIX 
is less accurate in this case than the one being used on Power.

Perhaps it would make sense to look at using darwin-ldouble.c (with 
function names appropriately adjusted) in some way on IRIX, in place of 
the code in fp-bit.c.  Since IRIX is the only target using the IBM long 
double support in fp-bit.c, it would then be possible to simplify fp-bit.* 
by removing all the HALFFRACBITS code.

Alternatively, if the format on IRIX is actually defined differently so 
that the nonzero bits are always within a contiguous set of 106 bits - if 
that is what IRIX documentation and the IRIX system compiler / libraries 
always do - then the generic code could be taught about that difference 
and the code in fp-bit.c might be closer to being correct for that 
definition than darwin-ldouble.c

[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #5 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
> (In reply to Vincent Lefèvre from comment #4)
>> I can see the same problem under Linux (gcc110.fsffrance.org).
>
> In case this wasn't clear, the architecture is also a PowerPC. The
> double-double format comes from the PowerPC ABI, and isn't directly related to
> the OS itself (FYI it was also used under Mac OS X / PowerPC).
>
> Thus the summary of this bug should be changed to:
>
>   LDBL_EPSILON is wrong on PowerPC

Certainly not: IRIX isn't PowerPC but MIPS!  If need be, just refer to
the double/double format.

    Rainer
>From gcc-bugs-return-427184-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 02 10:51:39 2013
Return-Path: <gcc-bugs-return-427184-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23213 invoked by alias); 2 Aug 2013 10:51:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23151 invoked by uid 48); 2 Aug 2013 10:51:36 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57408] lambda, Variable length arrays, thread, internal compiler error: in expand_expr_real_1, at expr.c:9327
Date: Fri, 02 Aug 2013 10:51:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: ice-on-invalid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution target_milestone
Message-ID: <bug-57408-4-TWfQBjgURB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57408-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57408-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00108.txt.bz2
Content-length: 562

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW408

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|jason at gcc dot gnu.org           |
         Resolution|---                         |FIXED
   Target Milestone|---                         |4.9.0

--- Comment #7 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Thus fixed for 4.9.0.

[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

[vincent-gcc at vinc17 dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #6)
> Certainly not: IRIX isn't PowerPC but MIPS!

OK, that wasn't clear because the original but report mentioned:
"gcc.target/powerpc/rs6000-ldouble-2.c".
            ^^^^^^^

> If need be, just refer to the double/double format.

Yes.
>From gcc-bugs-return-427186-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 02 11:00:20 2013
Return-Path: <gcc-bugs-return-427186-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4134 invoked by alias); 2 Aug 2013 11:00:20 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4045 invoked by uid 55); 2 Aug 2013 11:00:17 -0000
From: "ro at CeBiTec dot Uni-Bielefeld.DE" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5
Date: Fri, 02 Aug 2013 11:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-48341-4-iFP0GBr9qJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-48341-4@http.gcc.gnu.org/bugzilla/>
References: <bug-48341-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00110.txt.bz2
Content-length: 734

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #7 from Vincent Lefèvre <vincent-gcc at vinc17 dot net> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #6)
>> Certainly not: IRIX isn't PowerPC but MIPS!
>
> OK, that wasn't clear because the original but report mentioned:
> "gcc.target/powerpc/rs6000-ldouble-2.c".
>             ^^^^^^^

Right, but that test isn't run on regular testsuite runs on IRIX,
although there's nothing powerpc specific in there except for the
-mlong-double-128 option which can only be used on powerpc targets.

Running it manually on IRIX shows the failure.

    Rainer
>From gcc-bugs-return-427187-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 02 11:20:42 2013
Return-Path: <gcc-bugs-return-427187-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3011 invoked by alias); 2 Aug 2013 11:20:41 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 2904 invoked by uid 48); 2 Aug 2013 11:20:38 -0000
From: "schnoerr at mailzone dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/58057] gcc lexer cannot parse  extern "\x43" void blah() with option -std=c++0x;
Date: Fri, 02 Aug 2013 11:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: schnoerr at mailzone dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution short_desc
Message-ID: <bug-58057-4-sG13oL3ctf@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58057-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58057-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-08/txt/msg00111.txt.bz2
Content-length: 809

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX057

schnoerr at mailzone dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
                 CC|                            |schnoerr at mailzone dot com
         Resolution|WORKSFORME                  |---
            Summary|gcc lexer cannot parse      |gcc lexer cannot parse
                   |extern "\x43" void blah();  |extern "\x43" void blah()
                   |                            |with option -std=c++0x;

--- Comment #3 from schnoerr at mailzone dot com ---
sorry, I've forgotten a detail:
The problem only occurs with the option '-std=c++0x'.
With '-std=c++98' all works fine.

[Bug c/48341] LDBL_EPSILON is wrong on IRIX 6.5

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48341

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |4.8.0

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Vincent Lefèvre from comment #5)
> Thus the summary of this bug should be changed to:
> 
>   LDBL_EPSILON is wrong on PowerPC

That is already part of PR 61399.

Anyways IRIX support was removed in 2012 by r0-115719-gb24513a1a2bb35 for GCC
4.8.0.