| Summary: | Thumb2 instruction emitted for incompatible CPU | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Rafaël Carré <rafael.carre> |
| Component: | target | Assignee: | Richard Earnshaw <rearnsha> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | gcc-bugs, mikpelinux, rearnsha, rhill |
| Priority: | P3 | Keywords: | assemble-failure, wrong-code |
| Version: | 4.6.0 | ||
| Target Milestone: | 4.5.3 | ||
| Host: | Target: | arm-elf-eabi | |
| Build: | Known to work: | 4.5.0 | |
| Known to fail: | Last reconfirmed: | 2010-09-20 15:20:37 | |
| Attachments: |
Only emit MOVT when targetting Thumb2
Only emit MOVT when the targetted CPU is Thumb2-able |
||
I see the same on arm-linux-gnueabi with 4.6-20100907 and 4.5-20100916. It happens regardless of whether I pass -mcpu=arm9tdmi, -mcpu=armv5tel, or no -mcpu= at all. What binutils version are you using? movteq is a valid ARM v7 instruction. I made a CVS checkout of binutils yesterday. You're right, MOVT is supported on ARMv7 because all ARMv7 supports Thumb2, http://infocenter.arm.com/help/topic/com.arm.doc.qrc0001m/QRC0001_UAL.pdf (It says "All Thumb-2 versions of ARM v6 and above" so I suppose some ARMv6 CPU supports it too) But this instruction is emitted when an ARMv4 (mcpu=arm9tdmi) or ARMv5 (mcpu=armv5tel) CPU is used. Do you confuse ARM7 and ARMv7 ? ;) Created attachment 21844 [details]
Only emit MOVT when targetting Thumb2
Tentative patch.
However as suggested by the original TARGET_32BIT, your comment, and the binutils message; MOVT might be valid as well when targetting ARM?
Created attachment 21845 [details]
Only emit MOVT when the targetted CPU is Thumb2-able
Can you do a bisection to identify the exact commit responsible? Looking at the original commit that introduced the movt md pattern (139881) I see a TARGET_USE_MOVT guard in the C code that _should_ prevent it from being selected on non Thumb2-capable CPUs. If these guards are now broken then they need to be fixed. I didn't bisect. Did you try r139881? If I download a checkout (I'm using a snapshot) to bisect I could use this as a working starting point. TARGET_USE_MOVT uses arm_arch_thumb2 just like my patch so it's not broken. I double checked by adding an abort() in the 2 points where TARGET_USE_MOVT is tested in arm.c BTW I remember seeing this error in 4.5.0 and/or 4.5.1 but I don't have the builds around to verify. Must also be present (even if latent) on 4.5. Subject: Bug 45726 Author: rearnsha Date: Mon Sep 20 15:25:44 2010 New Revision: 164436 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164436 Log: 2010-09-20 Rafael Carre <rafael.carre@gmail.com> PR target/45726 * arm.md (arm_movtas_ze): Only enable on machine with MOVT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md Subject: Bug 45726 Author: rearnsha Date: Mon Sep 20 15:27:13 2010 New Revision: 164437 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164437 Log: 2010-09-20 Rafael Carre <rafael.carre@gmail.com> PR target/45726 * arm.md (arm_movtas_ze): Only enable on machine with MOVT. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/arm/arm.md Fixed in 4.5.3 and trunk. Is there something wrong with the first hunk of the patch (arm_movt) ? (In reply to comment #13) > Is there something wrong with the first hunk of the patch (arm_movt) ? > Nothing really. I missed that bit. I think in practice the compiler will never end up matching that pattern (as lo_sum isn't something the compiler spontaneously generates -- it means different things on each architecture that supports it, so the generic parts of the compiler will only use it if they are transforming something that already uses it), but it should probably be on the trunk version as the current code is clearly too liberal. Subject: Bug 45726 Author: rearnsha Date: Mon Sep 20 16:21:57 2010 New Revision: 164441 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164441 Log: 2010-09-20 Rafael Carre <rafael.carre@gmail.com> PR target/45726 * arm.md (arm_movt): Only enable on machines with MOVT. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md FWIW, exposed on trunk by r160462 (PR44423 fix), backported to 4.5 in r160775. But clearly the issue was latent since the movt patterns were added. Doesn't this second change also need to be on the 4.5 branch? Ignore that. |
% cat test.c union prop_data_t { unsigned int u; struct { unsigned short s1; unsigned short s2; }; }; union prop_data_t broken (int a, int b) { union prop_data_t var; if (a) { var.s2 = 0; var.s2 = b ? a : 2; if (var.s2) return var; } var.u = 0; return var; } % echo $CC /usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc % $CC -mcpu=arm9tdmi -c test.c -O -pipe {standard input}: Assembler messages: {standard input}:25: Error: selected processor does not support ARM mode `movteq r0,2' % $CC -mcpu=arm9tdmi -c test.c -Ofast -pipe {standard input}: Assembler messages: {standard input}:23: Error: selected processor does not support ARM mode `movteq r3,2' % $CC -mcpu=arm9tdmi -c test.c -pipe % $CC -v Using built-in specs. COLLECT_GCC=/usr/local/arm-elf-eabi-cvs/bin/arm-elf-eabi-gcc COLLECT_LTO_WRAPPER=/usr/local/arm-elf-eabi-cvs/libexec/gcc/arm-elf-eabi/4.6.0/lto-wrapper Target: arm-elf-eabi Configured with: ../gcc-4.6-20100918/configure --prefix=/usr/local/arm-elf-eabi-cvs --target=arm-elf-eabi --enable-lto --enable-languages=c --disable-docs --disable-libssp Thread model: single gcc version 4.6.0 20100918 (experimental) (GCC) % Using 20100918 snapshot reduced from http://svn.rockbox.org/viewvc.cgi/trunk/apps/plugins/goban/sgf.c?revision=20001&view=markup I tried to see which optimization broke with -Ox -Q --help=optimizers but the list printed doesn't seem to be complete.