sign-extending smaller modes

Jeffrey A Law law@cygnus.com
Tue Aug 8 15:02:00 GMT 2000


  In message < 200008082111.OAA10781@localhost.cygnus.com >you write:
  > > cc: dj@delorie.com, gcc-patches@gcc.gnu.org
  > > Reply-To: law@cygnus.com
  > > Date: Tue, 08 Aug 2000 13:35:50 -0600
  > > From: Jeffrey A Law <law@cygnus.com>
  > > 
  > >   In message < 200008081927.MAA05109@localhost.cygnus.com >you write:
  > >    > Jeffrey A Law <law@cygnus.com> writes:
  > >   > 
  > >   > > Interestingly enough, if I install your change I can't bootstrap th
  > e
  > >   > > PA port, so there's something happening that we don't quite underst
  > and.
  > >   > 
  > >   > I suspect this is a bug somewhere else.  One of the structural
  > >   > problems with gcc is that it doesn't make a proper distinction betwee
  > n
  > >   > arithmetic on the host and arithmetic on the target for integer
  > >   > values.  This causes lots and lots of problems whenever they differ.
  > > It was a *native* build.  The stage1 compiler mis-compiles the stage2
  > 
  > Well, included in my above statement is that 'arithmetic on the host'
  > means HOST_WIDE_INT, but 'arithmetic on the target' happens in some
  > particular mode which may or may not be the same as HOST_WIDE_INT.
  > In the case of the PA, which has SImode and DImode, one of them is
  > guaranteed to be different to HOST_WIDE_INT.
Err, no.

There are two distinct ports for the PA.  One for 32bit compilations, the
other for 64bit compilations (the reasons for this have been discussed
elsewhere).

A side effect of this is when doing native compiles on the PA,
HOST_WIDE_INT == word_mode.


  > Perhaps some problem in the PA's extensive bitfield operations?
  > I guess now someone has to actually debug it.  Do you have a PA
  > machine available?
Yes.  Machine cycles are easy to come by.  Mental cycles are not these days.

You're welcome to try it on one of the PAs in Sunnyvale...
jeff



More information about the Gcc-patches mailing list