tmp-lshift.s:106: Error: selected processor does not support ARM mode `vdup.32 d6, r3'

Niels Möller nisse at
Mon Dec 31 10:41:25 UTC 2018

Jeffrey Walton <noloader at> writes:

> Compile results in the following. According to Stallman I believe you
> are supposed to add the necessary options to compile the file
> independent of CFLAGS, and it should not need to be override-able by
> the user because it is required. Also see
> .

Note that section talks about make variables, and overriding them like

  make all CFLAGS=...

It's not talking about the configure settings with the same name. GMP
uses automake, and I don't know if automake-generated Makefiles conform
to that part of the GNU coding standads (it uses a bunch of different
*_CFLAGS make variables for different purposes), or if gmp's handling of
CFLAGS departs from automake conventions.

Anyway, to GMP's configure script, setting CFLAGS simply means "Just do
as I say; I know what I'm doing". So please don't specify CFLAGS that
makes the compiler not support the intended target platform.

> Assembler messages:
> tmp-lshift.s:106: Error: selected processor does not support ARM mode
> `vdup.32 d6,r3'

You don't tell us your intention. If you want to include neon code in
the build, and you specify CFLAGS yourself, you have to include whatever
options are needed to make the assembler recognize them. Or if you don't
want neon code, you must specify a configuration without neon support,
to exclude use of assembly files depending on neon.

For the specific case of neon, one alternative might be to explicitly
add the pseudo-op

   .fpu neon 

in all neon asm files, which should make them less dependent on flags
passed on the compiler command line. It looks like the definition of
ASM_START in mpn/arm/arm-defs.m4 can add that for us. So should we be


in all assembly files targetting neon?


Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

More information about the gmp-bugs mailing list