Fix -- Wide int sign extension in combine.c

Jeffrey A Law law@cygnus.com
Thu Feb 18 23:07:00 GMT 1999


  In message < 36C31851.386C696C@interix.com >you write:
  > Change to gcc.  When HOST_WIDE_INT is 64 bits.
  > Failure from testcase gcc.c-torture/930506-2.c.
What target?  I haven't seen this test failing on any of the 64bit MIPS
targets I work on regularly.

  > The code just prior to here computes smask, which is the sign-extended
  > (to HWI bits) version of the mask of 'interesting' bits, if a signed
  > number is involved.
Right. 

  > However, in computing the value argument to plus_constant, mask,
  > not smask, is used.  If XEXP(x,1) is negative, this masks off the
  > sign extension (from 32 to 64 bits, e.g.).
True, but what I don't see is why this is important.   If WIDTH is 32bits,
we don't actually care what's in the high bits.

Maybe an example would help.  ie, what are the values of the variables in
question.  Or better yet, a testcase.

I'm not saying you're wrong, I'm looking for more detailed information.


  > The prior changes outside the ifdef/endif:
  > It turns out that just the fix above causes an infinite recursion
  > in compiling gcc/tree.c (in this case, dealing with QI type).  Using
  > smask in these locations seems intuitively reasonable, fixes the
  > recursion, and improves the regression results.  (Note; the situation
  > is rare; tree.c is the first file compiled during a build that appears
  > to hit the problem.)
I'd like to see a testcase for this too.  There are some cases where 
nonzero_bits and friends can recurse infinitly, but they're problems  with
the state of the various reg_last_set* tables.


It sounds like you're trying to address two separate problems; we should
work on them separately -- ie, submit them as different patches with testcases.

That way if we agree that one of them is correct we can install it immediately
without having to wait on the other patch if it needs further review.

Thanks,
jeff


More information about the Gcc-patches mailing list