This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/47719] [4.6 regression] ICE compiling libavcodec/adxdec.c (FFmpeg) for ARM
- From: "jakub at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 3 Mar 2011 11:19:23 +0000
- Subject: [Bug target/47719] [4.6 regression] ICE compiling libavcodec/adxdec.c (FFmpeg) for ARM
- Auto-submitted: auto-generated
- References: <bug-47719-4@http.gcc.gnu.org/bugzilla/>
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.