http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57130
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> 2013-05-02
09:07:31 UTC ---
Created attachment 29994
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29994
gcc49-pr57130.patch
Untested fix, though not sure if it won't pessimize too much. The in_code ==
COMPARE handling simply look safe to me when recursing into a SUBREG.
Sometimes it could, e.g. for (subreg:SI (and:DI (reg:DI) (const_int
0x08000000))) with in_code == COMPARE, but we'd probably have to pass the
SUBREG mode around and special case it everywhere.
