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=2 -g -O2 -ffile-prefix-map=/<<PKGBUILDDIR>>=. -specs=/usr/share/dpkg/no-pie-compile.specs -fstack-protector-strong -Wformat -Werror=format-security -Wall -fno-pie -specs=/usr/share/
dpkg/no-pie-link.specs -Wl,-z,relro -Wl,-z,now -no-pie -pipe -nostdinc -D_REENTRANT -Os-fomit-frame-pointer -fstrict-aliasing -W -Wall -Wextra -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls -
Wshadow -c arm/__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

The code in question is:

#include "arm-features.h"

FUNC_START __longjmp
mov ip, r0
movs r0, r1
moveq r0, #1
#ifndef __SOFTFP__
# if __ARM_ARCH__ >= 6
vldm ip!, {d0-d15}

[…]

We don’t have __SOFTFP__ and we do have __ARM_ARCH__ >= 6,
obviously. So, why does this suddenly fail?

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 20, 2022 at 3:40 PM Thorsten Glaser <tg@debian.org> wrote:

Dixi quod…

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jul 20, 2022 at 9:35 PM Thorsten Glaser <tg@debian.org> wrote:

Dixi quod…

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dixi quod…

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
--
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. -- Andreas Bogk über boehm-gc in d.a.s.r

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Jeffrey Walton dixit:

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’m not mistaken.

(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’m not an ARM programmer though. The port was done by multiple others
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
--

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

Because I use lynx as browser.

+1
-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)