t-constants FAILs with GMP 6.2.1 on aarch64
Richard Biener
rguenther at suse.de
Wed Dec 9 07:42:18 UTC 2020
On Wed, 9 Dec 2020, Richard Biener wrote:
>
> See https://bugzilla.opensuse.org/show_bug.cgi?id=1179751 where
> Guillaume tracked this down to a change from GMP 6.2.0 to GMP 6.2.1.
>
> The issue shows up as
>
> Starting program: /home/abuild/rpmbuild/BUILD/gmp-6.2.1/tests/t-constants
> Missing separate debuginfos, use: zypper install
> glibc-debuginfo-2.32-3.3.aarch64
> PP_INVERTED == 21cfe6cfc938b36b, but pp_inverted_calc == 20f8c8b59d4cb9bc
>
> Reverting
>
> diff --git a/mpn/arm64/invert_limb.asm b/mpn/arm64/invert_limb.asm
> index a94b0e961..6a99bf002 100644
> --- a/mpn/arm64/invert_limb.asm
> +++ b/mpn/arm64/invert_limb.asm
> @@ -41,9 +41,9 @@ C Compiler generated, mildly edited. Could surely be
> further optimised.
> ASM_START()
> PROLOGUE(mpn_invert_limb)
> lsr x2, x0, #54
> - adrp x1, approx_tab
> + LEA_HI( x1, approx_tab)
> and x2, x2, #0x1fe
> - add x1, x1, :lo12:approx_tab
> + LEA_LO( x1, approx_tab)
> ldrh w3, [x1,x2]
> lsr x4, x0, #24
> add x4, x4, #1
>
> fixes the issue. Disassembly of the bogus libgmp routine is
> (via objdump)
>
> 000000000005d188 <__gmpn_invert_limb>:
> 5d188: d376fc02 lsr x2, x0, #54
> 5d18c: d0000181 adrp x1, 8f000
> <toom_eval_pm2exp.c.32b029f3+0x1d9>
> 5d190: 927f1c42 and x2, x2, #0x1fe
> 5d194: f9475c21 ldr x1, [x1, #3768]
> 5d198: 78626823 ldrh w3, [x1, x2]
> 5d19c: d358fc04 lsr x4, x0, #24
> 5d1a0: 91000484 add x4, x4, #0x1
>
> relocations of the object are
>
> Relocation section '.rela.text' at offset 0x558 contains 2 entries:
> Offset Info Type Sym. Value Sym. Name +
> Addend
> 000000000004 000100000137 R_AARCH64_ADR_GOT 0000000000000000 .text + 7c
> 00000000000c 000100000138 R_AARCH64_LD64_GO 0000000000000000 .text + 7c
>
> not sure what goes wrong, but the approx_tab data ends up in the .text
> section (so going via the GOT is even unnecessary - but I see the .asm
> file uses .DATA which hints at that it should go to .data or .rodata).
Btw, my config.m4 is the following which explains why I get approx_tab
in .text (and I guess a GOT relocation then simply invokes undefined
behavior?)
And GMP_ASM_RODATA likely arrives at the .text result since CFLAGS
includes -flto. Is there any reason to use CFLAGS in those tests?
The other tests seem to just switch on target systems or use
TRY_ASSEMBLE - that looks less fragile to me.
Defaulting to .text on aarch64 when using GOT relocations in asm
is probably asking for trouble (see my case), I think the test
should fail when running into
else
echo "Couldn't find label:
^${tmp_gsym_prefix}foo$gmp_cv_asm_label_suffix" >&AC_FD_CC
rather than falling back to .text. Alternatively all targets that
use explicit references to [RO]DATA should have a safer default.
What's the collection of RODATA results "supported"? As said a
switch like for GMP_ASM_GLOBL looks less error-prone here.
Richard.
dnl config.m4. Generated automatically by configure.
changequote(<,>)
ifdef(<__CONFIG_M4_INCLUDED__>,,<
define(<CONFIG_TOP_SRCDIR>,<`../.'>)
define(<WANT_ASSERT>,0)
define(<WANT_PROFILING>,<`no'>)
define(<M4WRAP_SPURIOUS>,<no>)
define(<TEXT>, <.text>)
define(<DATA>, <.data>)
define(<LABEL_SUFFIX>, <:>)
define(<GLOBL>, <.globl>)
define(<GLOBL_ATTR>, <>)
define(<GSYM_PREFIX>, <>)
define(<RODATA>, <.text>)
define(<TYPE>, <.type $1,@$2>)
define(<SIZE>, <.size $1,$2>)
define(<LSYM_PREFIX>, <.L>)
define(<W32>, <.long>)
define(<ALIGN_LOGARITHMIC>,<yes>)
define(<SQR_TOOM2_THRESHOLD>,<18>)
define(<BMOD_1_TO_MOD_1_THRESHOLD>,<40>)
define(<SIZEOF_UNSIGNED>,<4>)
define(<GMP_LIMB_BITS>,64)
define(<GMP_NAIL_BITS>,0)
define(<GMP_NUMB_BITS>,eval(GMP_LIMB_BITS-GMP_NAIL_BITS))
>)
changequote(`,')
ifdef(`__CONFIG_M4_INCLUDED__',,`
include(CONFIG_TOP_SRCDIR`/mpn/asm-defs.m4')
include_mpn(`arm64/arm64-defs.m4')
define_not_for_expansion(`HAVE_HOST_CPU_aarch64')
define_not_for_expansion(`HAVE_ABI_64')
define_not_for_expansion(`HAVE_LIMB_LITTLE_ENDIAN')
define_not_for_expansion(`HAVE_DOUBLE_IEEE_LITTLE_ENDIAN')
')
define(`__CONFIG_M4_INCLUDED__')
More information about the gmp-devel
mailing list