NetBSD Problem Report #52520

From www@NetBSD.org  Sat Sep  2 00:36:13 2017
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 3657C7A234
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  2 Sep 2017 00:36:13 +0000 (UTC)
Message-Id: <20170902003612.673067A271@mollari.NetBSD.org>
Date: Sat,  2 Sep 2017 00:36:12 +0000 (UTC)
From: coypu@sdf.org
Reply-To: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Subject: Wrong double to uint64_t conversion
X-Send-Pr-Version: www-1.0

>Number:         52520
>Category:       port-alpha
>Synopsis:       Wrong double to uint64_t conversion
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-alpha-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Sep 02 00:40:00 +0000 2017
>Closed-Date:    Sat Apr 11 16:27:50 +0000 2020
>Last-Modified:  Sat Apr 11 16:27:50 +0000 2020
>Originator:     coypu
>Release:        NetBSD 8.99.2
>Organization:
>Environment:
NetBSD gemini.duskware.de 8.99.2 NetBSD 8.99.2 (GENERIC-$Revision: 1.376 $) #2: Mon Aug 28 13:00:23 CEST 2017  martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/alpha/compile/GENERIC.MP alpha

>Description:
the following test case asserts if built with -mieee, but not without:

#include <assert.h>
#include <inttypes.h>
#include <stdint.h>

int
main (void)
{
        long double even = 9223372036854775808.000000; /* 2^63 */
        uint64_t unsigned_even = even;

        assert(unsigned_even % 2 == 0);

        return 0;
}

This took a while to make sense of, and appears to be a kernel bug.
Here is my reasoning to help a non-expert along:

2^63: valid float, valid uint64_t, invalid int64_t.

  Because we are building with -mieee, it is also effectively built with -mfp-trap-mode=su

  The code generated is the following:
    cvttq/svc  $f10,$f11

  According to the alpha manual, "V" means that we trap on integer overflow.
  CVTTQ probably thinks in terms of signed integers, so (I think) unsigned 2^63 traps.

  The kernel must complete it, but it does so incorrectly.   We get unsigned_even == 2^63 - 1.

note this bug came from MPFR's testsuite. other things may fail too.
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:
From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-alpha/52520: Wrong double to uint64_t conversion
Date: Sun, 3 Sep 2017 09:56:57 +0000

 As I understand it, the reason for emulating alpha is its inability to
 handle inf and subnormals.
 All valid results of double-to-int conversions aren't inf or subnormals.

 I'm strongly inclined to believe cvttq does the right thing calculating
 the numerical result for valid inputs by itself, so doesn't need
 amendment. but perhaps we still need to set some status flag, and of
 course - not SIGFPE.


 Side notes:
 - GCC generates code with 'cvttq' even without -mieee, rather than
   cvtgq. so IEEE may be the default anyway.


 - cvttq (IEEE T_floating to quadword) and cvtgq (vax G_float to quadword)
   share an emulation function, cvt_gq_tq. But they don't share a format!

   we probably shouldn't attempt to emulate any VAX float, but I haven't
   put much thought into this. As I understand it, Alpha implements vax
   float correctly unassisted.

From: coypu@sdf.org
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-alpha/52520: Wrong double to uint64_t conversion
Date: Sun, 3 Sep 2017 10:42:51 +0000

 As for the cause of the bug, it's:

 .. -> cvt_tq_gq -> float64_to_int64 -> roundAndPackInt64:

   overflow:
          float_raise( float_flag_invalid );
          return
                zSign ? (sbits64) LIT64( 0x8000000000000000 )
              : LIT64( 0x7FFFFFFFFFFFFFFF );


 "float64_to_int64 does what the name says", whereas we needed
 _to_uint64.

 I would really like the opinion of someone who didn't hear about alpha
 FPU yesterday rather than make broad changes myself.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52520 CVS commit: src/sys
Date: Sun, 31 Dec 2017 11:43:43 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Sun Dec 31 11:43:42 UTC 2017

 Modified Files:
 	src/sys/arch/alpha/alpha: fp_complete.c
 	src/sys/lib/libkern: softfloat.c softfloat.h

 Log Message:
 PR port-alpha/52520: provide float64 -> uint64 conversion and use
 that when converting positive numbers.


 To generate a diff of this commit:
 cvs rdiff -u -r1.21 -r1.22 src/sys/arch/alpha/alpha/fp_complete.c
 cvs rdiff -u -r1.5 -r1.6 src/sys/lib/libkern/softfloat.c
 cvs rdiff -u -r1.4 -r1.5 src/sys/lib/libkern/softfloat.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: maya@netbsd.org
To: gnats-bugs@netbsd.org
Cc: martin@netbsd.org
Subject: Re: port-alpha/52520: Wrong double to uint64_t conversion
Date: Sat, 13 Jan 2018 15:17:42 +0000

 Hi martin,

 can we pull this up to -8 and possibly further?
 (It's your machine :))

From: "Soren Jacobsen" <snj@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/52520 CVS commit: [netbsd-8] src/sys
Date: Mon, 26 Feb 2018 01:23:42 +0000

 Module Name:	src
 Committed By:	snj
 Date:		Mon Feb 26 01:23:42 UTC 2018

 Modified Files:
 	src/sys/arch/alpha/alpha [netbsd-8]: fp_complete.c
 	src/sys/lib/libkern [netbsd-8]: softfloat.c softfloat.h

 Log Message:
 Pull up following revision(s) (requested by maya in ticket #584):
 	sys/arch/alpha/alpha/fp_complete.c: 1.22
 	sys/lib/libkern/softfloat.c: 1.6
 	sys/lib/libkern/softfloat.h: 1.5
 PR port-alpha/52520: provide float64 -> uint64 conversion and use
 that when converting positive numbers.


 To generate a diff of this commit:
 cvs rdiff -u -r1.21 -r1.21.20.1 src/sys/arch/alpha/alpha/fp_complete.c
 cvs rdiff -u -r1.5 -r1.5.22.1 src/sys/lib/libkern/softfloat.c
 cvs rdiff -u -r1.4 -r1.4.80.1 src/sys/lib/libkern/softfloat.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->needs-pullups
State-Changed-By: maya@NetBSD.org
State-Changed-When: Mon, 26 Feb 2018 11:39:36 +0000
State-Changed-Why:
Should probably do -7 too (as well as the FP_GETMASK change)


State-Changed-From-To: needs-pullups->closed
State-Changed-By: maya@NetBSD.org
State-Changed-When: Sat, 11 Apr 2020 16:27:50 +0000
State-Changed-Why:
in netbsd-8, seems pretty far back.


>Unformatted:

Home	PR Database Search