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.
