From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 99CEA3858C98; Wed, 28 Feb 2024 04:19:24 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 99CEA3858C98
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1709093964;
	bh=J5qSq5UCRRcKcuXjTq+O5Rfd2oBjGr6ShbJRcfiYUAY=;
	h=From:To:Subject:Date:From;
	b=a8g/2T8vu6pxq9lAAYMnsuHp2RhwlTh76glmy+8+yCTogY4CcbsVT7xi3r4khMqmp
	 AcpwJ8v0MENXoj8WrvOw7JbBN3eppNt9/oQKDIWb7k61kFEJhSvOrlYn9s3iFoVj86
	 +3QiGr7ymLGA8mCXNIlrbFiMSraymGX+LGERRBZE=
From: "hp at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/114143] New: Non-thumb arm32 code in thumb multilib for
 libgcc and  in -mthumb build
Date: Wed, 28 Feb 2024 04:19:24 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 13.2.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hp at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
 cf_gcctarget
Message-ID: <bug-114143-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D114143

            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-e=
abi,
I expect the simplest thumb1 library code in libraries linked in when I com=
pile
and link the main code using e.g. -O2 -mcpu=3Dcortex-m7+nofp -msoft-float. =
 To my
surprise, I get 32-bit ("arm32") code linked in.  Needless to say, it crash=
es
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 s=
ome
optimized functions implemented in assembly code (like strcmp), but that ma=
y 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=3Darmv7e-m at configure-=
time,
I think a "plain" arm-eabi configuration being unusable for thumb-only buil=
ds
with -mthumb is a bug or at least a surprising caveat worth being documente=
d.

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=3Dcortex-m7+nofp -O2" simulat=
ing
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=3Dcortex-m7+nofp" to make sure you get the right multilib.  Inspect ab
using arm-eabi-objdump -d.  Observe udivide calling  __udivsi3, with __udiv=
si3
containing arm32 code.=