Combine known_cond() may create subreg of const_int

[Alexandre Oliva]

Given the following rtx:

(if_then_else (ne (reg:DI #1) (const_int 0))
  (reg:DI #2)
  (reg:DI #1))

combine would crash while replacing (reg:DI #1) with (zero_extend:DI
(subreg:QI (reg:DI #3) 7)).  

We thus simplify the if_then_else condition to:

              (ne (reg:DI #3) (const_int 0))

The elimination of zero_extend and subreg is valid because the subreg
is a low part, and reg:DI #3 is known to have all bits other than the
least-significant one set to zero.

so we now have:

(if_then_else (ne (reg:DI #3) (const_int 0))
  (reg:DI #2)
  (zero_extend:DI (subreg:QI (reg:DI #3) 7)))

then we get to simplify_if_then_else(), and it substs (reg:DI #3) with
(const_int 0) in the `else' rtx.  known_cond() makes it:

(if_then_else (ne (reg:DI #3) (const_int 0))
  (reg:DI #2)
  (zero_extend:DI (subreg:QI (const_int 0) 7)))

and then it crashes later on, when it attempts to simplify_subreg this
RTX because the original inner mode of the subreg was lost.

This patch arranges for us to attempt to simplify the subreg before we
lose track of its mode.  However, I wonder if it would be best to fold
this logic into do_SUBST, and/or to handle ZERO_EXTEND and SIGN_EXTEND
similarly.  Is this ok to install?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: combine-known-subreg.patch
Type: text/x-patch
Size: 1087 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20020211/8c1cd640/attachment.bin>
-------------- next part --------------

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer