[Bug rtl-optimization/71976] insn-combiner deletes a live 64-bit shift

["gjl at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71976

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2016-07-25
            Summary|[avr] insn-combiner deletes |insn-combiner deletes a
                   |a live 64-bit shift         |live 64-bit shift
     Ever confirmed|0                           |1

--- Comment #6 from Georg-Johann Lay <gjl at gcc dot gnu.org> ---
This also happens on current trunk r238700 from today (2016-07-25).

After substitution from
       (ashiftrt:DI (reg:DI 18 r18)
                    (reg:QI 16 r16))
to
        (ashiftrt:DI (reg:DI 18 r18)
                     (const_int 40))

combine calls

simplify_shift_const_1 (code=ASHIFTRT, result_mode=DImode,
varop=0x7ffff734ee70, orig_count=40) at
../../../gcc.gnu.org/trunk/gcc/combine.c:10181

(gdb) p varop
$95 = (rtx) 0x7ffff734ee70
(gdb) pr
(reg:DI 18 r18)

And then there is this piece of code:

      /* An arithmetic right shift of a quantity known to be -1 or 0
         is a no-op.  */
      if (code == ASHIFTRT
          && (num_sign_bit_copies (varop, shift_mode)
              == GET_MODE_PRECISION (shift_mode)))
        {
          count = 0;
          break;
        }

How can it conclude the quantity to be shifted (reg:DI 18) is always 0 or -1?
This is simply not the case.