Sign-extend CONST_INTs within their modes

Alexandre Oliva aoliva@redhat.com
Fri Mar 30 05:57:00 GMT 2001


On Mar 18, 2001, Geoff Keating <geoffk@geoffk.org> wrote:

> Alexandre Oliva <aoliva@redhat.com> writes:
>> A while ago, I proposed a patch that would auto-detect the need for
>> 64-bits HOST_WIDE_INTs, and it ended up rejected because some targets
>> broke with a wider-than-32-bits HOST_WIDE_INT because GCC wouldn't
>> sign-extend CONST_INTs as it should.

>> I've come up with a patch to detect occurrences of non-sign-extended
>> CONST_INTs, and fixed all errors it detected on a port I'm working on,
>> in which I enabled 64-bit HOST_WIDE_INTs.  There are certainly more
>> bugs lurking around, in chunks of code not exercised by this port, but
>> I'd like to install the fixes I've found so far, and maybe the test to
>> detect invalid values too (it's the changes in recog.c).

>> This has only been tested with the new port.  I intend to test it on
>> alpha and probably a few alpha-x-??? crosses.  Suggestions?

> I believe the original trouble was on PA, if you could try a build
> there, that would be good.

It bootstrapped fine on alpha.  For a x86 bootstrap, I had to tweak
the argument mode promotion rules in integrate.c.  For a sparc
bootstrap, I had to tweak expand_binop so as to handle widening
conversions properly.  For a pa bootstrap, I had to fix
expand_end_case() so as to convert minval and range to the appropriate
modes.  Then, for a alpha-x-ppc `make all-target', I needed a couple
of tweaks in the rs6000 configuration files.

>> Ok to install the codegen fixes?  What about the recog changes?

> The codegen fixes (other than the varasm.c change) are all OK, put
> them in if the compiler survives a bootstrap & test on alpha.  The
> varasm.c change can go in if it also survives an x86 bootstrap & test
> and a PA bootstrap & test, I figure if it works on those three natives
> it's probably no worse than the current situation.  The recog change
> is OK (if the others go in) but I'd like to see it controlled by
> another flag than RTL_CHECKING, as RTL_CHECKING is very expensive and
> these tests are not (perhaps --enable-checking=misc?), and be prepared
> to disable it if problems are reported that you can't quickly fix.

Here's the updated patch.  Ok to install?



More information about the Gcc-patches mailing list