[Bug rtl-optimization/58997] ICE on valid code at -O3 on x86_64-linux-gnu (affecting gcc trunk and 4.8.2)

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

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58997

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2013-11-05
                 CC|                            |jakub at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 31158
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31158&action=edit
gcc49-pr58997.patch

Untested fix.  Likely regressed in r110005.  For IV_UNKNOWN_EXTEND,
get_iv_value
returns value in iv->mode rather than iv->extend_mode, so for iv_subreg we just
need to adjust the last argument to lowpart_subreg.  For iv_extend similarly,
but IMHO (no testcase) if iv->extend is not unknown, but different from
currently required extend, then the code misbehaves too, say for iv->extend
IV_SIGN_EXTEND what get_iv_value returns is say HImode sign extended into
SImode, if we do iv_extend IV_ZERO_EXTEND to say DImode on this, then it would
give us for negative HImode a value with bits 16-31 all set rather than clear.
And, additionally (again, no testcase), the uses in may_unswitch_on I can't see
how we couldn't end up with get_iv_value returning there zero resp. sign
extended op[i], i.e. wider than we want.  If the other IV isn't sign/zero
extended, or is extended to different mode or differently, or if the other
operand is constant (which should be sign extended from the mode), I'd say this
can create invalid RTL or wrong-code.