This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: patch: Sign-extension bug (?) in immed_double_const



  In message <20000914183037.A12444@daikokuya.demon.co.uk>you write:
  > Jeffrey A Law wrote:-
  > 
  > > This can't be correct.
  > > 
  > > Consider :
  > > 
  > > BITS_PER_WORD 32
  > > HOST_BITS_PER_WIDE_INT 32
  > > width 64
  > > i0 0x80180481
  > > i1 0
  > > 
  > > Your change will turn that into
  > > 
  > > i0 0xffffffff
  > > i1 0x0
  > > 
  > > Which can't be correct.
  > > 
  > > The "|| i1 == 0" clause seems totally bogus to me.  I have no idea what y
  > ou
  > > were trying to accomplish with that change, but it can't be right as writ
  > ten.
  > 
  > I agree it's not correct (it fails the stage2 compilation towards the
  > very end, on tmp-dum.c of all places).  However, in the example you give
  > I think i0 and i1 remain unchanged.
No, those results are from real runs with your patch installed.  Your change
looks like this:

+      if (((BITS_PER_WORD < HOST_BITS_PER_WIDE_INT && BITS_PER_WORD == width)
+           || i1 == 0)
          && (i0 & ((HOST_WIDE_INT) 1 << (width - 1))))

Which is equivalent to

       if (((32 < 32 && 32 == 64)
           || 0 == 0)
          && (0x80180481 & (1 << (64 - 1))))

Which, yes has an invalid shift.  Depending on show the shift is implemented,
then it may change i1 as shown above.  The PA ignores the upper bits of the
shift count.  So it simplies into

	if (((0 < 0 && 0)
             || 1)
            && (0x80180481 & (1 << 31)))

Which simplifies into

       if (((0)
            || 1)
           && (0x80180481 & (0x80000000)))

Which simplies to 1.
 

  > The problem I have / had is finding documentation on the correct
  > representation of signed and unsigned constants in trees and rtx
  > types, and when extended to wider / narrower modes.  The source of the
  > bug is the constant being treated as signed in once place but not in
  > another, and with various conversions going on it gets very confusing.
No doubt.  It's a bloody mess.

jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]