From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-335792-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 6745 invoked by alias); 20 Jan 2013 21:43:02 -0000
Received: (qmail 6723 invoked by uid 22791); 20 Jan 2013 21:43:00 -0000
X-SWARE-Spam-Status: No, hits=-1.1 required=5.0	tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RDNS_NONE
X-Spam-Check-By: sourceware.org
Received: from Unknown (HELO mout.gmx.net) (212.227.15.19)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 20 Jan 2013 21:42:52 +0000
Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LtC3J-1Sw7Hr1o0h-012mya for <gcc-patches@gcc.gnu.org>; Sun, 20 Jan 2013 22:42:44 +0100
Received: (qmail 29080 invoked by uid 0); 20 Jan 2013 21:42:44 -0000
Received: from 79.216.213.225 by www013.gmx.net with HTTP; Sun, 20 Jan 2013 22:42:41 +0100 (CET)
Cc: gcc-patches@gcc.gnu.org, binutils@sourceware.org
Content-Type: text/plain; charset="utf-8"
Date: Sun, 20 Jan 2013 21:43:00 -0000
From: =?iso-8859-1?Q?=22J=FCrgen_Urban=22?= <JuergenUrban@gmx.de>
In-Reply-To: <alpine.DEB.1.10.1301172232280.4834@tp.orcam.me.uk>
Message-ID: <20130120214241.59480@gmx.net>
MIME-Version: 1.0
References: <20130106225645.190700@gmx.net> <87y5g43bkf.fsf@talisman.default> <alpine.DEB.1.10.1301072351450.4834@tp.orcam.me.uk> <20130108223433.27430@gmx.net> <alpine.DEB.1.10.1301090616540.4834@tp.orcam.me.uk> <20130113141555.89760@gmx.net> <alpine.DEB.1.10.1301140419140.4834@tp.orcam.me.uk> <20130117222059.231610@gmx.net> <alpine.DEB.1.10.1301172232280.4834@tp.orcam.me.uk>
Subject: Re: Support for MIPS r5900
To: "Maciej W. Rozycki" <macro@codesourcery.com>
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2013-01/txt/msg01035.txt.bz2

Hello Maciej,

> > I tested the calculation with the type "float".
> > ABI o32 with -mhard-float and -msingle-float produces the following
> results:
> > 1.000000 (0x3f800000) / 0.000000 (0x00000000) = nan (0x7fffffff)
> > 0.000000 (0x00000000) / 0.000000 (0x00000000) = nan (0x7fffffff)
> > 0.000000 (0x00000000) / nan (0x7fc00000) = 0.000000 (0x00000000)
> > 1.000000 (0x3f800000) + 1.000000 (0x3f800000) = 2.000000 (0x40000000)
> > 1.000000 (0x3f800000) + inf (0x7f800000) = inf (0x7f800000)
> > inf (0x7f800000) + inf (0x7f800000) = nan (0x7fffffff)
> > inf (0x7f800000) + -inf (0xff800000) = 0.000000 (0x00000000)
> > nan (0x7fc00000) + nan (0x7fc00000) = nan (0x7fffffff)
> > nan (0x7fc00000) + nan (0xffc00000) = 0.000000 (0x00000000)
> > 
> > The r5900 manual calls the result of 0/0 Fmax. So 0x7fffffff seems to be
> Fmax.
> 
>  So presumably you can get 0x7fffffff as an arithmetic result of a 
> calculation involving regular numbers as well, right?  Say 0x7f7ffffe + 
> 0x74000000 (using the binary-encoded notation)?  That would be beyond the
> IEEE-754 single range.

The FPU of the r5900 calculates the following:
340282306073709652508363335590014353408.000000 (0x7f7ffffd) + 40564819207303340847894502572032.000000 (0x74000000) = 340282346638528859811704183484516925440.000000 (0x7f7fffff)
340282326356119256160033759537265639424.000000 (0x7f7ffffe) + 40564819207303340847894502572032.000000 (0x74000000) = inf (0x7f800000)
340282346638528859811704183484516925440.000000 (0x7f7fffff) + 40564819207303340847894502572032.000000 (0x74000000) = inf (0x7f800000)
inf (0x7f800000) + 40564819207303340847894502572032.000000 (0x74000000) = nan (0x7f800001)
nan (0x7f800001) + 40564819207303340847894502572032.000000 (0x74000000) = nan (0x7f800002)
nan (0x7f900000) + 40564819207303340847894502572032.000000 (0x74000000) = nan (0x7f900001)
nan (0x7f900001) + 40564819207303340847894502572032.000000 (0x74000000) = nan (0x7f900002)
nan (0x7ffffff1) + 40564819207303340847894502572032.000000 (0x74000000) = nan (0x7ffffff2)
nan (0x7ffffffc) + 40564819207303340847894502572032.000000 (0x74000000) = nan (0x7ffffffd)
nan (0x7ffffffd) + 40564819207303340847894502572032.000000 (0x74000000) = nan (0x7ffffffe)
nan (0x7ffffffe) + 40564819207303340847894502572032.000000 (0x74000000) = nan (0x7fffffff)
nan (0x7fffffff) + 40564819207303340847894502572032.000000 (0x74000000) = nan (0x7fffffff)

So it seems that it interprets nan and inf as normal numbers, but it stops at 0x7fffffff. So 0x7fffffff should be interpreted as overflow.

Best regards
Jürgen