https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114143
Bug ID: 114143 Summary: Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hp at gcc dot gnu.org Target Milestone: --- Target: arm-eabi Building an arm-eabi newlib toolchain configured simply with --target arm-eabi, I expect the simplest thumb1 library code in libraries linked in when I compile and link the main code using e.g. -O2 -mcpu=cortex-m7+nofp -msoft-float. To my surprise, I get 32-bit ("arm32") code linked in. Needless to say, it crashes for this reason on the target Cortex-M7 system. On inspection the linked-in thumb multilib is full of 32-bit code. Ditto some of the newlib code for some optimized functions implemented in assembly code (like strcmp), but that may be a separate bug unless the preprocessor macros that newlib uses in the build, are wrong for the same reason as in this PR. While I can work around this by adding --with-arch=armv7e-m at configure-time, I think a "plain" arm-eabi configuration being unusable for thumb-only builds with -mthumb is a bug or at least a surprising caveat worth being documented. Example code, for a tool-chain configured with --target arm-eabi as above: a.c; compile with "-O2 -mthumb" to simulate other library code: ``` unsigned udivide(unsigned a, unsigned b) { return a / b; }''' b.c; compile with "-msoft-float -mthumb -mcpu=cortex-m7+nofp -O2" simulating code you care about: ```extern unsigned udivide(unsigned, unsigned); int main() { __builtin_exit (udivide(42, 6)); }''' Link a.o and b.o producing ab using gcc with e.g. "-msoft-float -mthumb -mcpu=cortex-m7+nofp" to make sure you get the right multilib. Inspect ab using arm-eabi-objdump -d. Observe udivide calling __udivsi3, with __udivsi3 containing arm32 code.