vldm on armhf?

[Thorsten Glaser]

Hi,

did something change wrt. compiler defaults on armhf recently?

The almost unchanged upload of dietlibc todays fails on armhf
(albeit on an arm64 buildd):

gcc -D__dietlibc__ -I. -isystem include -Wdate-time -D_FORTIFY_SOURCE=3D2 -=
g -O2 -ffile-prefix-map=3D/<<PKGBUILDDIR>>=3D. -specs=3D/usr/share/dpkg/no-=
pie-compile.specs -fstack-protector-strong -Wformat -Werror=3Dformat-securi=
ty -Wall -fno-pie -specs=3D/usr/share/dpkg/no-pie-link.specs -Wl,-z,relro -=
Wl,-z,now -no-pie -pipe -nostdinc -D_REENTRANT -Os-fomit-frame-pointer -fst=
rict-aliasing -W -Wall -Wextra -Wchar-subscripts -Wmissing-prototypes -Wmis=
sing-declarations -Wno-switch -Wno-unused -Wredundant-decls -Wshadow -c a=
rm/__longjmp.S -Wa,--noexecstack -o bin-arm/__longjmp.o
arm/__longjmp.S: Assembler messages:
arm/__longjmp.S:9: Error: selected processor does not support `vldm ip!,{d0=
-d15}' in ARM mode
make[2]: *** [Makefile:206: bin-arm/__longjmp.o] Error 1

#include "arm-features.h"
FUNC_START __longjmp
mov ip, r0
movs r0, r1
moveq r0, #1
#ifndef __SOFTFP__
# if __ARM_ARCH__ >=3D 6
vldm ip!, {d0-d15}

[=E2=80=A6]

We don=E2=80=99t have __SOFTFP__ and we do have __ARM_ARCH__ >=3D 6,
obviously. So, why does this suddenly fail?

Thanks in advance,
//mirabilos
--=20
If Harry Potter gets a splitting headache in his scar
when he=E2=80=99s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
=09-- me, wondering why it=E2=80=99s not Jerry Potter=E2=80=A6=E2=80=A6=E2=
=80=A6

[Thorsten Glaser]

Dixi quod=E2=80=A6

Post by Thorsten Glaser
did something change wrt. compiler defaults on armhf recently?

armel also FTBFS with SIGILL in the testsuite.

So something changed incompatibly between 2019-11-10 and now
in the ARM toolchain. But what, and how can I get this to work
again?

Thanks in advance,
//mirabilos
--=20
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.=09=09-- Andreas Bogk =C3=BCber boehm-gc in d.a.s.r

[Jeffrey Walton]

Dixi quod…

Post by Thorsten Glaser
did something change wrt. compiler defaults on armhf recently?

armel also FTBFS with SIGILL in the testsuite.
So something changed incompatibly between 2019-11-10 and now
in the ARM toolchain. But what, and how can I get this to work
again?

If I recall correctly... Debian now uses ARMv7 for a default, which
enables NEON in the compiler. Automatically enabling NEON based on
ARMv7 is a GCC 11 change.

(I thought Debian's armel went away recently).

Also see GCC Bug 104455, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104455 .

Jeff

[Thorsten Glaser]

Post by Jeffrey Walton
If I recall correctly... Debian now uses ARMv7 for a default, which
enables NEON in the compiler. Automatically enabling NEON based on
ARMv7 is a GCC 11 change.

Hmmh. But armhf used ARMv7 by default before, too, if I=E2=80=99m not mista=
ken.

Post by Jeffrey Walton
(I thought Debian's armel went away recently).

Nope, still very much active and listed as release architecture even.
(And even if not, debian-ports do exist, and we want to support as many
as possible.)

I=E2=80=99m not an ARM programmer though. The port was done by multiple oth=
ers
and IIRC even slightly diverges from what upstream currently has, as
we collected bugfixes in Debian which upstream ignored. So the specific
details of which subarchitectures have which instructions are a bit
beyond my paygrade (I do know about the differences between arm, armeb,
armel, armhf-raspian, armhf-everyoneelse and arm64 though, just on a
somewhat higher level).

bye,
//mirabilos
--=20

Post by Jeffrey Walton

Why don't you use JavaScript? I also don't like enabling JavaScript in

Because I use lynx as browser.

+1
=09-- Octavio Alvarez, me and =E2=A1=8D=E2=A0=81=E2=A0=97=E2=A0=8A=E2=A0=95=
(Mario Lang) on debian-devel

[Arnd Bergmann]

Dixi quod…

Post by Thorsten Glaser
did something change wrt. compiler defaults on armhf recently?

armel also FTBFS with SIGILL in the testsuite.
So something changed incompatibly between 2019-11-10 and now
in the ARM toolchain. But what, and how can I get this to work
again?

gcc changed the way that you pass the floating point instruction set,
so instead of -march=armv7-a one should now pass -march=armv7-a+fp
to pick a target CPU that includes vfpv3-d16 FPU.

My guess is that in your case the compiler gets the wrong target CPU
and passes that down to the assembler, which then refuses to build
using FPU instructions.

Arnd

[Thorsten Glaser]

Post by Arnd Bergmann
gcc changed the way that you pass the floating point instruction set,
so instead of -march=3Darmv7-a one should now pass -march=3Darmv7-a+fp
to pick a target CPU that includes vfpv3-d16 FPU.

But we pass neither!

$ git grep -F armv7- | wc -l

0

Post by Arnd Bergmann
My guess is that in your case the compiler gets the wrong target CPU
and passes that down to the assembler, which then refuses to build
using FPU instructions.

Hmm. So rebuild with -v on a porterbox?

bye,
//mirabilos
--=20
<ch> you introduced a merge commit =E2=94=82<mika> % g rebase -i HEA=
D^^
<mika> sorry, no idea and rebasing just fscked =E2=94=82<mika> Segmentation
<ch> should have cloned into a clean repo =E2=94=82 fault (core dumpe=
d)
<ch> if I rebase that now, it's really ugh =E2=94=82<mika:#grml> wuahhh=
hhh