sign-extending smaller modes
Jeffrey A Law
Tue Aug 8 15:02:00 GMT 2000
In message < 200008082111.OAA10781@localhost.cygnus.com >you write:
> > cc: email@example.com, firstname.lastname@example.org
> > Reply-To: email@example.com
> > Date: Tue, 08 Aug 2000 13:35:50 -0600
> > From: Jeffrey A Law <firstname.lastname@example.org>
> > In message < 200008081927.MAA05109@localhost.cygnus.com >you write:
> > > Jeffrey A Law <email@example.com> writes:
> > >
> > > > Interestingly enough, if I install your change I can't bootstrap th
> > > > PA port, so there's something happening that we don't quite underst
> > >
> > > 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
> > > 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.
There are two distinct ports for the PA. One for 32bit compilations, the
other for 64bit compilations (the reasons for this have been discussed
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...
More information about the Gcc-patches