[Bug target/114143] New: Non-thumb arm32 code in thumb multilib for libgcc and in -mthumb build

[hp at gcc dot gnu.org]

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.