From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by sourceware.org (Postfix) with ESMTPS id C2400382A2E7 for ; Mon, 31 Oct 2022 15:49:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C2400382A2E7 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=danielengel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=danielengel.com Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B0DC53200917; Mon, 31 Oct 2022 11:49:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Mon, 31 Oct 2022 11:49:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielengel.com; h=cc:cc:content-transfer-encoding:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1667231346; x= 1667317746; bh=bKElXalJZQMT+CjSWucYChGinYakKFZjJVQNXBweoh0=; b=a s8vXXB3FhY09IC/cB4W3oRajuZOckR3J4x/Zd3w8/U0st6VAF2mjbWGGdZbW75p0 +bx+k3cJHqjuXlqNM9rZmW0CgL39MP3HcG9TP+xsPop2hOR944mNV4Qm2kioZvC4 AEykQ4GZn90YpEgL9odmg6MpBJ6mWXp5u4XgzRNFccepsSUj5POZ/zbzxCLuQIhq EeTdf7I1B8MH09HSizBph+GpVtwBPxom2KUYqMrmVPVr2afSS09TpuQPr/aGTYRj eoV4QhgrclpEcv1uEnkaKwhV/x1Qc/kk1EXETlJO7x/BYV3fGsSqTVheaWfe1sR/ 1jt6/eXgQPXrDOet3lXlg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1667231346; x=1667317746; bh=bKElXalJZQMT+ CjSWucYChGinYakKFZjJVQNXBweoh0=; b=QKVUiprgRqBgm/A3QTqrFEWa+1sY3 IUzyI2ndg9NbTjrq+s0pfE/9+jiIUumZ+S3wn8f8reMZUU9XGjldH9WaT0IZYpGe g+JvPXb9VQyVFeMcQT/Zr0lkYP/olhlAuke6QDsfcrFQl39iWs7EznfNRc5xjucs cHxHfd9AmJybn2rNZ3IFvWeplXRAfD61uD6Hlf2zNSWekzSytxydlXbLOTv/2/Ki 856/cqI7J04AQN463npcQ3RAxWY69+oJV+78q2cxehPWmPi3LszQ0SddGNG2AqMg i9NkzS+r1ZF6++siQKXXzkKlgoQxLjZWeEjhvRgxC7voK83v9CEZstmaA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrudefgdektdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkffojghfggfgsedtkeertdertddtnecuhfhrohhmpeffrghnihgv lhcugfhnghgvlhcuoehgnhhusegurghnihgvlhgvnhhgvghlrdgtohhmqeenucggtffrrg htthgvrhhnpefggeekleduieelueegvdehvdegjedvgefgtddvfeeuvedvveetffehhfdu jefggeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hgnhhusegurghnihgvlhgvnhhgvghlrdgtohhm X-ME-Proxy: Feedback-ID: i791144d6:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 31 Oct 2022 11:49:05 -0400 (EDT) Received: from ubuntu.lorien.danielengel.com (ubuntu.lorien.danielengel.com [10.0.0.96]) by sendmail.lorien.danielengel.com (8.15.2/8.15.2) with ESMTP id 29VFmvYD087328; Mon, 31 Oct 2022 08:48:57 -0700 (PDT) (envelope-from gnu@danielengel.com) From: Daniel Engel To: Richard Earnshaw , gcc-patches@gcc.gnu.org Cc: Daniel Engel , Christophe Lyon Subject: [PATCH v7 33/34] Drop single-precision Thumb-1 soft-float functions Date: Mon, 31 Oct 2022 08:45:28 -0700 Message-Id: <20221031154529.3627576-34-gnu@danielengel.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20221031154529.3627576-1-gnu@danielengel.com> References: <20221031154529.3627576-1-gnu@danielengel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-13.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: With the complete CM0 library integrated, regression testing showed new failures with the message "compilation failed to produce executable": gcc.dg/fixed-point/convert-float-1.c gcc.dg/fixed-point/convert-float-3.c gcc.dg/fixed-point/convert-sat.c Investigating, this appears to be caused by the linker. I can't find a comprehensive linker specification to claim this is actually a bug, but it certainly doesn't match my expectations. Investigating, I found issues with the link order of these symbols: * __aeabi_fmul() * __aeabi_f2d() * __aeabi_f2iz() Specifically, I expect the linker to import the _first_ definition of any symbol. This is the basic behavior that allows the soft-float library to supply missing symbols on architectures without optimized routines. Comparing the v6-m multilib with the default, I see symbol exports for all of the affect symbols: gcc-obj/gcc/libgcc.a: // assembly routines _arm_mulsf3.o: 00000000 W __aeabi_fmul 00000000 W __mulsf3 _arm_addsubdf3.o: 00000368 T __aeabi_f2d 00000368 T __extendsfdf2 _arm_fixsfsi.o: 00000000 T __aeabi_f2iz 00000000 T __fixsfsi mulsf3.o: fixsfsi.o: extendsfdf2.o.o: gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a: // assembly routines _arm_mulsf3.o: 00000000 T __aeabi_fmul U __fp_assemble U __fp_exception U __fp_infinity U __fp_zero 00000000 T __mulsf3 U __umulsidi3 _arm_fixsfsi.o: 00000000 T __aeabi_f2iz 00000000 T __fixsfsi 00000002 T __internal_f2iz _arm_f2d.o: 00000000 T __aeabi_f2d 00000000 T __extendsfdf2 U __fp_normalize2 // soft-float library mulsf3.o: 00000000 T __aeabi_fmul fixsfsi.o: 00000000 T __aeabi_f2iz extendsfdf2.o: 00000000 T __aeabi_f2d Given the order of the archive file, I expect the linker to import the affected functions from the _arm_* archive elements. For "convert-sat.c", all is well with -march=armv7-m. ... (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_muldf3.o OK> (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_mulsf3.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_cmpsf2.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_fixsfsi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_fixunssfsi.o OK> (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_addsubdf3.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_cmpdf2.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_fixdfsi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_arm_fixunsdfsi.o OK> (/home/mirdan/gcc-obj/gcc/libgcc.a)_fixsfdi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_fixdfdi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_fixunssfdi.o (/home/mirdan/gcc-obj/gcc/libgcc.a)_fixunsdfdi.o ... However, with -march=armv6s-m, the linker imports these symbols from the soft- float library. (NOTE: The CM0 library only implements single-precision float operations, so imports from muldf3.o, fixdfsi.o, etc are expected.) ... ??> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)mulsf3.o ??> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)fixsfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)muldf3.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)fixdfsi.o ??> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)extendsfdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_clzsi2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fcmpge.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fcmple.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixsfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunssfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunssfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_cmpdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunsdfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixdfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunsdfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)eqdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)gedf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)ledf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)subdf3.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)floatunsidf.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_cmpsf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixsfsi.o ... It seems that the order in which the linker resolves symbols matters. In the affected test cases, the linker begins searching for fixed-point function symbols first: _subQQ.o, _cmpQQ.o, etc. The fixed-point archive elements appear after the _arm_* archive elements, so the initial definitions of the floating point functions are discarded. However, the fixed-point functions contain unresolved symbol references which the linker registers progressively. Given that the default libgcc.a does not build the soft-point library [1], the linker cannot import any floating point objects until the second pass. However, when v6-m/nofp/libgcc.a _does_ include the soft-point library, the linker proceeds to import some floating point objects during the first pass. To test this theory, add explicit symbol references to convert-sat.c: --- a/gcc/testsuite/gcc.dg/fixed-point/convert-sat.c +++ b/gcc/testsuite/gcc.dg/fixed-point/convert-sat.c @@ -11,6 +11,12 @@ extern void abort (void); int main () { + volatile float a = 1.0; + volatile float b = 2.0; + volatile float c = a * b; + volatile double d = a; + volatile int e = a; + SAT_CONV1 (short _Accum, hk); SAT_CONV1 (_Accum, k); SAT_CONV1 (long _Accum, lk); Afterwards, the linker imports the expected symbols: ... ==> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_mulsf3.o ==> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_muldi3.o ==> (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fixsfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_f2d.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fp_exceptionf.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fp_assemblef.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fp_normalizef.o ... (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)muldf3.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)fixdfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_clzsi2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fixunssfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fcmpge.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fcmple.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fixsfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_fixunssfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_cmpdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunsdfsi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixdfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_fixunsdfdi.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)eqdf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)gedf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)ledf2.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)subdf3.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)floatunsidf.o (/home/mirdan/gcc-obj/gcc/thumb/v6-m/nofp/libgcc.a)_arm_cmpsf2.o ... At a minimum this behavior results in the use of non-preferred code in an affected application. However, as long as each object exports a single entry point, this does not automatically result in a build failure. Indeed, in the case of __aeabi_fmul() and __aeabi_f2d(), all references seem to resolve uniformly in favor of the soft-float library. The first pass that imports the soft-float version of __aeabi_f2iz() also succeeds. However, the first pass fails to find __aeabi_f2uiz(), since the soft-float library does not implement this variant. So, this symbol remains undefined until the second pass. However, the assembly version of __aeabi_f2uiz() the linker finds happens to be implemented as a branch to __internal_f2iz() [2]. But the linker, importing __internal_f2iz(), also finds the main entry point __aeabi_f2iz(). And, since __aeabi_f2iz() was already found in the soft-float library, the linker throws an error. The solution is two-fold. First, the assembly routines have separately been made robust against this potential error condition (by weakening and splitting symbols). Second, this commit to block single-precision functions from the soft-float library makes it impossible for the linker to select a non-preferred version. Two duplicate symbols remain (extendsfdf2) and (truncdfsf2), but the situation is much improved. [1] softfp_wrap_start = "#if !__ARM_ARCH_ISA_ARM && __ARM_ARCH_ISA_THUMB == 1" [2] (These operations share a substantial portion of their code path, so this choice leads to a size reduction in programs that use both functions.) gcc/libgcc/ChangeLog: 2022-10-09 Daniel Engel * config/arm/t-softfp (softfp_float_modes): Added as "df". --- libgcc/config/arm/t-softfp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libgcc/config/arm/t-softfp b/libgcc/config/arm/t-softfp index 554ec9bc47b..bd6a4642e5f 100644 --- a/libgcc/config/arm/t-softfp +++ b/libgcc/config/arm/t-softfp @@ -1,2 +1,4 @@ softfp_wrap_start := '\#if !__ARM_ARCH_ISA_ARM && __ARM_ARCH_ISA_THUMB == 1' softfp_wrap_end := '\#endif' +softfp_float_modes := df + -- 2.34.1