Bug#996419: gcc-11: Fails to compile the linux kernel on ARM.

[Sebastian Andrzej Siewior]

Package: gcc-11
Version: 11.2.0-9
Severity: important

The linux kernel has the following in its ARM Makefile:
$(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a)

This means the switch "-march=armv7-a" is tested if supported by the
compiler and if so it is used, otherwise it uses the alternative
"-march=armv5t -Wa,-march=armv7-a".

On gcc-10 it evaluated to "-march=armv7-a".
On gcc-11 it evaluates to "-march=armv5t -Wa,-march=armv7-a" leading to
compile errors:
| cccHPwDp.s:4372: Error: selected processor does not support `cpsid i' in ARM mode
| cccHPwDp.s:5145: Error: selected processor does not support `cpsid i' in ARM mode
| cccHPwDp.s:5393: Error: selected processor does not support `cpsie i' in ARM mode
| cccHPwDp.s:5530: Error: selected processor does not support `dsb ' in ARM mode
| cccHPwDp.s:6088: Error: selected processor does not support `cpsie i' in ARM mode
| cccHPwDp.s:7132: Error: architectural extension `mp' is not allowed for the current base architecture
| cccHPwDp.s:7133: Error: selected processor does not support `pldw [r4]' in ARM mode
| cccHPwDp.s:7136: Error: selected processor does not support `pld [r4]' in ARM mode
| cccHPwDp.s:7148: Error: selected processor does not support `ldrex r3,[r4]' in ARM mode
| cccHPwDp.s:7150: Error: selected processor does not support `strex r1,r2,[r4]' in ARM mode

This has been noticed in the gcc-11-arm-linux-gnueabihf package and
verified on a armhf porter box with the native gcc-11 package.

The test fails due to:
| $ arm-linux-gnueabihf-gcc-10 -o a.o a.c -march=armv7-a
| $ arm-linux-gnueabihf-gcc-11 -o a.o a.c -march=armv7-a
| cc1: error: ‘-mfloat-abi=hard’: selected architecture lacks an FPU

Passing early -msoft-float to the compiler test solves the problem. This
option is passed later to the compile process.
Is this change intended?

Sebastian

[Matthias Klose]

The change is intended; the configure changes are already in GCC 8, but the
configure options that we used, are now being deprecated upstream.

Changes: https://gcc.gnu.org/gcc-8/changes.html

> On gcc-10 it evaluated to "-march=armv7-a".
> On gcc-11 it evaluates to "-march=armv5t -Wa,-march=armv7-a" leading to

-march=armv7-a+fp probably should be used. Same in assembler files where armv7-a
is used as an architecture. I'm not a kernel developer however, so don't know if
this is the intended approach.

[Sebastian Andrzej Siewior]

On 2021-10-16 12:17:40 [+0200], Matthias Klose wrote:
> The change is intended; the configure changes are already in GCC 8, but the
> configure options that we used, are now being deprecated upstream.
>
> Changes: https://gcc.gnu.org/gcc-8/changes.html

I guess you refer to
| The -march and -mcpu options now accept optional extensions…

which describes the syntax. But this is gcc-8 introducing new syntax not
gcc-11 dropping old syntax or so.

> > On gcc-10 it evaluated to "-march=armv7-a".
> > On gcc-11 it evaluates to "-march=armv5t -Wa,-march=armv7-a" leading to
>
> -march=armv7-a+fp probably should be used. Same in assembler files where armv7-a
> is used as an architecture. I'm not a kernel developer however, so don't know if
> this is the intended approach.

I was asking because `gcc -v' changes from
--with-arch=armv7-a --with-fpu=vfpv3-d16
to
--with-arch=armv7-a+fp

and I wasn't sure if this is intended or a side effect. But it may be
mandatory due to the new syntax.

As for the option, I would guess "armv7-a+nofp" since the expectation is
not to clobber any FPU/SIMD registers like in auto-vectorization etc.
But I see Arnd is on Cc: and silently hope he looks into it ;)

Sebastian

[Arnd Bergmann]

On Mon, Oct 18, 2021 at 9:03 AM Sebastian Andrzej Siewior
<seba...@breakpoint.cc> wrote:
> On 2021-10-16 12:17:40 [+0200], Matthias Klose wrote:
> > The change is intended; the configure changes are already in GCC 8, but the
> > configure options that we used, are now being deprecated upstream.
> >
> > Changes: https://gcc.gnu.org/gcc-8/changes.html
>
> I guess you refer to
> | The -march and -mcpu options now accept optional extensions…
>
> which describes the syntax. But this is gcc-8 introducing new syntax not
> gcc-11 dropping old syntax or so.

From what I understand now, gcc-11 did not actually change, only the
way that gcc is packaged in Debian and Ubuntu changed at [1].
This has apparently gone back and forth a couple of time, but I don't
recall anyone reporting the kernel build regression before, so I assume
the new way is not yet widely used outside of debian.

What happens is that the kernel tries out the configured -march=
options individually, falling back to e.g. -march=armv5t if we can't
build for -march=armv6. Once it has established the -march=
argument, it adds further flags like -msoft-float, since the kernel
itself is built without floating-point instructions disabled.

On builds of gcc-11, this would lead to compiling with

-march=armv6 -mfpu=vfpv3-d16 -mfloat-abi=hard

to override the -march=armv7-a. On new builds, there is no -mfpu=vfp3-d16,
so it attempts and fails to build with

-march=armv6 -mfloat-abi=hard

and then falls back to -march=armv5t with -msoft-float added in the
next step. Building an ARMv6 kernel with -march=armv5t fails when
the assembler rejects inline assembly statements with newer instructions.

> > > On gcc-10 it evaluated to "-march=armv7-a".
> > > On gcc-11 it evaluates to "-march=armv5t -Wa,-march=armv7-a" leading to
> >
> > -march=armv7-a+fp probably should be used. Same in assembler files where armv7-a
> > is used as an architecture. I'm not a kernel developer however, so don't know if
> > this is the intended approach.
>
> I was asking because `gcc -v' changes from
> --with-arch=armv7-a --with-fpu=vfpv3-d16
> to
> --with-arch=armv7-a+fp
>
> and I wasn't sure if this is intended or a side effect. But it may be
> mandatory due to the new syntax.
>
> As for the option, I would guess "armv7-a+nofp" since the expectation is
> not to clobber any FPU/SIMD registers like in auto-vectorization etc.
> But I see Arnd is on Cc: and silently hope he looks into it ;)

I'll send the kernel workaround soon, and that should make it into all
stable kernels.

The compilers I build for kernel.org do not set a default -march value
and end up with the default that gcc picks, which apparently is
a softfloat -mcpu=arm10tdmi.

Arnd

[1] https://salsa.debian.org/toolchain-team/gcc/-/commit/0070c26305320144b5e049ae12e1adfec82f508

[Matthias Klose]

On 10/18/21 9:03 AM, Sebastian Andrzej Siewior wrote:
> On 2021-10-16 12:17:40 [+0200], Matthias Klose wrote:
>> The change is intended; the configure changes are already in GCC 8, but the
>> configure options that we used, are now being deprecated upstream.
>>
>> Changes: https://gcc.gnu.org/gcc-8/changes.html
>
> I guess you refer to
> | The -march and -mcpu options now accept optional extensions…
>
> which describes the syntax. But this is gcc-8 introducing new syntax not
> gcc-11 dropping old syntax or so.
>
>>> On gcc-10 it evaluated to "-march=armv7-a".
>>> On gcc-11 it evaluates to "-march=armv5t -Wa,-march=armv7-a" leading to
>>
>> -march=armv7-a+fp probably should be used. Same in assembler files where armv7-a
>> is used as an architecture. I'm not a kernel developer however, so don't know if
>> this is the intended approach.
>
> I was asking because `gcc -v' changes from
> --with-arch=armv7-a --with-fpu=vfpv3-d16
> to
> --with-arch=armv7-a+fp
>
> and I wasn't sure if this is intended or a side effect. But it may be
> mandatory due to the new syntax.

CCing Richard. I've been told that the --with-fpu configure option is deprecated
now, therefore changing the way this is configured.

> As for the option, I would guess "armv7-a+nofp" since the expectation is
> not to clobber any FPU/SIMD registers like in auto-vectorization etc.
> But I see Arnd is on Cc: and silently hope he looks into it ;)

I also backported
"ARM: pass architecture extensions to assembler if supported." from the trunk,
applied in the gcc-11 Debian package.
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579897.html

Matthias

[Salvatore Bonaccorso]

For cross-reference:

On Mon, Oct 18, 2021 at 11:52:31AM +0200, Arnd Bergmann wrote:
[...]

> I'll send the kernel workaround soon, and that should make it into all
> stable kernels.
>
> The compilers I build for kernel.org do not set a default -march value
> and end up with the default that gcc picks, which apparently is
> a softfloat -mcpu=arm10tdmi.

The mentioned kernel workaround/patch would be
https://lore.kernel.org/linux-arm-kernel/20211018140735...@kernel.org/
(not yet applied in mainline and other stable series).

Regards,
Salvatore