NetBSD Problem Report #35561

From www@NetBSD.org  Wed Feb  7 18:17:39 2007
Return-Path: <www@NetBSD.org>
Received: by narn.NetBSD.org (Postfix, from userid 31301)
	id 3152163BB12; Wed,  7 Feb 2007 18:17:39 +0000 (UTC)
Message-Id: <20070207181739.3152163BB12@narn.NetBSD.org>
Date: Wed,  7 Feb 2007 18:17:39 +0000 (UTC)
From: arthur@ilvsun3.com
Reply-To: arthur@ilvsun3.com
To: gnats-bugs@NetBSD.org
Subject: gcc-3.3.3 generates invalid assembly code on m68k platform
X-Send-Pr-Version: www-1.0

>Number:         35561
>Category:       port-m68k
>Synopsis:       gcc-3.3.3 generates invalid assembly code on m68k platform
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-m68k-maintainer
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 07 18:20:00 +0000 2007
>Closed-Date:    Thu May 13 07:36:33 +0000 2010
>Last-Modified:  Thu May 13 07:36:33 +0000 2010
>Originator:     arthur townsend
>Release:        3.0
>Organization:
>Environment:
3.0 for sun3
>Description:
Using the default gcc-3.3.3 under NetBSD 3.0 for Sun3, the following command:
gcc -save-temps -c -O2 art9.c

generates the error:
art9.s: Assembler messages:
art9.s:68: Error: operands mismatch -- statement 'move.b %a0,%d1' ignored.

The c source statement that causes the error is the "add192" line.  It is easy to see that the assembly line in question is indeed invalid (possibly the %a0 should be in parenthesis or move.b should be move.l).

The same problem occurs with gcc-3.2.3 running under SunOS 4.1.1.

typedef unsigned char tme_uint8_t;
typedef tme_uint8_t flag;
typedef signed char tme_int8_t;
typedef tme_int8_t int8;

typedef int __int32_t;
typedef __int32_t int32_t;
typedef signed int tme_int32_t;
typedef tme_int32_t int32;

typedef unsigned long long int tme_uint64_t;
typedef tme_uint64_t bits64;
typedef signed long long int tme_int64_t;
typedef tme_int64_t sbits64;

typedef struct {
  tme_uint64_t low;
  tme_uint64_t high;
} float128;

extern float128 roundAndPackFloat128( flag, int32, bits64, bits64, bits64 );

static inline void
 add192(
     bits64 a0,
     bits64 a1,
     bits64 a2,
     bits64 b0,
     bits64 b1,
     bits64 b2,
     bits64 *z0Ptr,
     bits64 *z1Ptr,
     bits64 *z2Ptr
 )
{ 
    bits64 z0, z1, z2;
    int8 carry0, carry1;
    z2 = a2 + b2;
    carry1 = ( z2 < a2 );
    z1 = a1 + b1;
    carry0 = ( z1 < a1 );
    z0 = a0 + b0;
    z1 += carry1;
    z0 += ( z1 < (bits64) carry1 );
    z0 += carry0;
    *z2Ptr = z2;
    *z1Ptr = z1;
    *z0Ptr = z0;

}

float128 float128_div( float128 a, float128 b )
{
    flag aSign, bSign, zSign;
    int32 aExp, bExp, zExp;
    bits64 aSig0, aSig1, bSig0, bSig1, zSig0, zSig1, zSig2;
    bits64 rem0, rem1, rem2, rem3, term0, term1, term2, term3;
    float128 z;

    while ( (sbits64) rem0 < 0 ) {
        --zSig0;
        add192( rem0, rem1, rem2, 0, bSig0, bSig1, &rem0, &rem1, &rem2 );
    }

    return roundAndPackFloat128( zSign, zExp, zSig0, zSig1, zSig2 );

}

>How-To-Repeat:
Attempt to make TME from pkgsrc, or compile the above test case with -O2.

>Fix:

>Release-Note:

>Audit-Trail:

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Thu, 31 Dec 2009 19:14:19 +0000
State-Changed-Why:
Is this fixed in gcc4?


From: Ignatios Souvatzis <is@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: port-m68k/35561
Date: Wed, 5 May 2010 11:06:55 +0200

 Note bene: I'm not the submitter of this PR, but...

 With this cross-compiler:

 > /var/itch/sources/cur/tools/m68k--netbsdelf/bin/gcc -v                        Using built-in specs.
 Target: m68k--netbsdelf
 Configured with: /var/itch/sources/cur/src/tools/gcc/../../gnu/dist/gcc4/configure --target=m68k--netbsdelf --enable-long-long --enable-threads --enable-__cxa_atexit --disable-nls --disable-multilib --program-transform-name=s,^,m68k--netbsdelf-, --enable-languages=c c++ objc --prefix=/var/itch/sources/cur/src/../tools
 Thread model: posix
 gcc version 4.1.3 20080704 (prerelease) (NetBSD nb2 20081120)


 the provided test-case seems to compile without error (that is: no
 error message, especially no move.b on address registers is produced).

 I tested -m68020, -m68030, -m68040, -m68060, -m68020-60 with -O2,
 and -Os, -O0, -O1, -O2, -O3, -O6 with the standard machine.

 I think this PR can be closed.

 Regards,
 	-is

State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Thu, 13 May 2010 07:36:33 +0000
State-Changed-Why:
Fixed in gcc4. (Thanks to is@ for testing.)


>Unformatted:

Home	PR Database Search