Bug 7250 - __ashrdi3 returns wrong value on 32 bit hppa
__ashrdi3 returns wrong value on 32 bit hppa
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: target
3.0.2
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2002-07-09 13:36 UTC by Steve Ellcey
Modified: 2003-07-25 17:33 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
x.c (79 bytes, application/octet-stream)
2003-05-21 15:17 UTC, Steve Ellcey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Steve Ellcey 2002-07-09 13:36:01 UTC
Arithmatic right shift of long long (64 bit) value returns wrong value.  See attached file (x.c) for a program that
fails with -O0 (with call to __ashrdi3) but works with optimization because the call is optimized away.

Release:
3.0.2

Environment:
hppa1.1-hp-hpux11.00

How-To-Repeat:
Compile x.c and run it *without* optimization on a 32 bit PA machine.  With optimization it works.
Comment 1 Steve Ellcey 2002-07-09 16:12:56 UTC
From: Steve Ellcey <sje@cup.hp.com>
To: law@redhat.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: target/7250: __ashrdi3 returns wrong value on 32 bit hppa
Date: Tue, 9 Jul 2002 16:12:56 -0700 (PDT)

 Oh poo.  I hate it when I do something stupid.  I was printing out the
 value of a "long long" variable with a "%d" format instead of "%lld" and
 the random garbage that I got made it look I was getting different
 results.
 
 I thought this was causing a problem that popped up when I updated cse.c
 and got a new change but it looks like that is a different problem and
 is now fixed in a cse.c patch I just saw in gcc-patches.
 
 This defect can be closed.  Can I close it myself or do I need some
 permssion to do that?  I have write-after-approval permission for the
 GCC tree but I haven't tried messing about with GNAT other then to
 submit a defect.
 
 Steve Ellcey
 sje@cup.hp.com
Comment 2 Jeffrey A. Law 2002-07-09 16:48:46 UTC
From: Jeff Law <law@porcupine.slc.redhat.com>
To: sje@cup.hp.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: target/7250: __ashrdi3 returns wrong value on 32 bit hppa 
Date: Tue, 09 Jul 2002 16:48:46 -0600

 In message <20020709203142.10159.qmail@sources.redhat.com>, sje@cup.hp.com writ
 es:
  >
  >>Number:         7250
  >>Category:       target
  >>Synopsis:       __ashrdi3 returns wrong value on 32 bit hppa
  >>Confidential:   no
  >>Severity:       serious
  >>Priority:       medium
  >>Responsible:    unassigned
  >>State:          open
  >>Class:          sw-bug
  >>Submitter-Id:   net
  >>Arrival-Date:   Tue Jul 09 13:36:01 PDT 2002
  >>Closed-Date:
  >>Last-Modified:
  >>Originator:     sje@cup.hp.com
  >>Release:        3.0.2
  >>Organization:
  >>Environment:
  >hppa1.1-hp-hpux11.00
  >>Description:
  >Arithmatic right shift of long long (64 bit) value returns wrong value.  See 
  >attached file (x.c) for a program that
  >fails with -O0 (with call to __ashrdi3) but works with optimization because t
  >he call is optimized away.
  >
  >>How-To-Repeat:
  >Compile x.c and run it *without* optimization on a 32 bit PA machine.  With o
  >ptimization it works.
 Can you look a little deeper into this?  It seems quite odd that
 ashrdi3 would return the wrong value for a shift count of zero as
 it special cases zero count in libgcc2.c:
 
 DWtype
 __ashrdi3 (DWtype u, word_type b)
 {
   DWunion w;
   word_type bm;
   DWunion uu;
 
   if (b == 0)
     return u;
 
 
 [ ... ]
 
 Jeff
 

Comment 3 Jeffrey A. Law 2002-07-10 11:47:26 UTC
State-Changed-From-To: open->closed
State-Changed-Why: Thinko, not a bug.
Comment 4 Jeffrey A. Law 2002-07-10 12:51:15 UTC
From: Jeff Law <law@porcupine.slc.redhat.com>
To: Steve Ellcey <sje@cup.hp.com>
Cc: law@redhat.com, gcc-gnats@gcc.gnu.org
Subject: Re: target/7250: __ashrdi3 returns wrong value on 32 bit hppa 
Date: Wed, 10 Jul 2002 12:51:15 -0600

 In message <200207092312.QAA07337@hpsje.cup.hp.com>, Steve Ellcey writes:
  >Oh poo.  I hate it when I do something stupid.  I was printing out the
  >value of a "long long" variable with a "%d" format instead of "%lld" and
  >the random garbage that I got made it look I was getting different
  >results.
 No problem.
 
  >This defect can be closed.  Can I close it myself or do I need some
  >permssion to do that?  I have write-after-approval permission for the
  >GCC tree but I haven't tried messing about with GNAT other then to
  >submit a defect.
 I took care of it.
 jeff