NetBSD Problem Report #49273

From www@NetBSD.org  Sat Oct 11 12:12:28 2014
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id AEFD7A665A
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 11 Oct 2014 12:12:28 +0000 (UTC)
Message-Id: <20141011121227.68EBEA6662@mollari.NetBSD.org>
Date: Sat, 11 Oct 2014 12:12:27 +0000 (UTC)
From: ragge@ludd.ltu.se
Reply-To: ragge@ludd.ltu.se
To: gnats-bugs@NetBSD.org
Subject: 64-bit constant loads in as will be truncated to 32-bit.
X-Send-Pr-Version: www-1.0

>Number:         49273
>Category:       toolchain
>Synopsis:       64-bit constant loads in as will be truncated to 32-bit.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          suspended
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Oct 11 12:15:00 +0000 2014
>Closed-Date:    
>Last-Modified:  Mon Oct 13 04:45:33 +0000 2014
>Originator:     Anders Magnusson
>Release:        6.1.5
>Organization:
>Environment:
NetBSD nbvax.tethuvudet.se 6.1.5 NetBSD 6.1.5 (GENERIC) vax
>Description:
movq of a small negative constant will be truncated to 32-bit.
For example, movq $-1,-(%sp) will create wrong code but movq $-88888888888,-(%sp) will work.


>How-To-Repeat:
nbvax:/home/ragge/pcc/cc/ccom >as
movq $-1,-(%sp)
movq $-20000000000,-(%sp)
movq $-2000000000,-(%sp)
nbvax:/home/ragge/pcc/cc/ccom >objdump -d a.out

a.out:     file format elf32-vax


Disassembly of section .text:

00000000 <.text>:
   0:   7d 8f ff ff     movq $0x00000000ffffffff,-(sp)  # wrong
   4:   ff ff 00 00 
   8:   00 00 7e 
   b:   7d 8f 00 38     movq $0xfffffffb57e83800,-(sp)  # correct
   f:   e8 57 fb ff 
  13:   ff ff 7e 
  16:   7d 8f 00 6c     movq $0x0000000088ca6c00,-(sp)  # wrong
  1a:   ca 88 00 00 
  1e:   00 00 7e 

>Fix:

>Release-Note:

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: toolchain/49273: 64-bit constant loads in as will be truncated to 32-bit.
Date: Sat, 11 Oct 2014 14:30:42 +0200

 On Sat, Oct 11, 2014 at 12:15:00PM +0000, ragge@ludd.ltu.se wrote:
 > movq of a small negative constant will be truncated to 32-bit.

 There was a lengthy discussion of this on the gcc lists, with (IIRC)
 a settlement to use long hex constants instead; gcc has a special
 VAX specific format identifier for movq constants now.

 Martin

From: Anders Magnusson <ragge@ludd.ltu.se>
To: gnats-bugs@NetBSD.org, toolchain-manager@NetBSD.org,
        gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/49273: 64-bit constant loads in as will be truncated
 to 32-bit.
Date: Sat, 11 Oct 2014 14:45:32 +0200

 Solving it from a compiler perspective is not a problem,
 but as should nevertheless either accept these values correctly
 or complain,  not just silently ignore them :-)

 -- Ragge

From: Anders Magnusson <ragge@ludd.ltu.se>
To: gnats-bugs@NetBSD.org, toolchain-manager@NetBSD.org,
        gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: toolchain/49273: 64-bit constant loads in as will be truncated
 to 32-bit.
Date: Sat, 11 Oct 2014 16:11:27 +0200

 I just noted that vax as never warns, even if it is an overflow in an 
 instruction, like "bicl3 $0xe8d4a50ffe,b,%r0" where the value just is 
 truncated without complaints.  Not especially kind to programmers :-)

 -- Ragge

From: Martin Husemann <martin@duskware.de>
To: Anders Magnusson <ragge@ludd.ltu.se>
Cc: gnats-bugs@NetBSD.org, toolchain-manager@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: toolchain/49273: 64-bit constant loads in as will be truncated to 32-bit.
Date: Sat, 11 Oct 2014 16:36:12 +0200

 On Sat, Oct 11, 2014 at 02:45:32PM +0200, Anders Magnusson wrote:
 > Solving it from a compiler perspective is not a problem,
 > but as should nevertheless either accept these values correctly
 > or complain,  not just silently ignore them :-)

 Bring it up with the binutils folks (and good luck).

 There is a comment in the code:

                           p[0] = (operandP->vop_mode << 4) | 0xF;
                           if ((is_absolute) && (expP->X_op != O_big))  
                             {
                               /* If nbytes > 4, then we are scrod. We
                                  don't know if the high order bytes  
                                  are to be 0xFF or 0x00.  BSD4.2 & RMS
                                  say use 0x00. OK --- but this
                                  assembler needs ANOTHER rewrite to
                                  cope properly with this bug.  */

 (gas/config/tc-vax.c:3312ff)


 Martin

State-Changed-From-To: open->suspended
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 13 Oct 2014 04:45:33 +0000
State-Changed-Why:
upstream bug
(unless someone wants to try to fix it in binutils, in which case take
the PR and update the state)


>Unformatted:

Home	PR Database Search