http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47719
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P1 CC| |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-03 11:19:10 UTC --- Marking as P1; ARM people, can this be resolved soon, so that it doesn't block 4.6 release for too long? As the comments in postreload.c say, it might turn a movhi into zero_extendhisi2 or movqi into extendqisi2 for TARGET_THUMB, for arm_arch4 just movqi into zero_extendqisi2 and for BYTES_BIG_ENDIAN movhi into extendhisi2. Not sure for which of the myriad of arm subtargets minipool is applicable though, or if minipool is even applicable for movqi. But if you emit some assembly insn which in one case needs minipool attributes and from another zero/sign extend insn you emit exactly the same assembly, but don't have the minipool attributes on it, it is a bug.