[GCC6] fatal error: You must enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use these intrinsics.

[Igor Gnatenko]

https://bugzilla.redhat.com/show_bug.cgi?id=1307783

Looks like it failed on armv7 with this error, but it was working before...
Any ideas?

In file included from
/builddir/build/BUILD/mozjs-31.2.0/mfbt/tests/TestEndian.cpp:6:0:
../../dist/include/mozilla/Endian.h: In function 'void
swapFromNetworkOrderInPlace(T*, size_t) [with T = short unsigned
int]':
../../dist/include/mozilla/Endian.h:175:45: fatal error: You must
enable NEON instructions (e.g. -mfloat-abi=softfp -mfpu=neon) to use
these intrinsics.
     return MOZ_HAVE_BUILTIN_BYTESWAP16(value);
                                             ^
compilation terminated.


-- 

-Igor Gnatenko

[Peter Robinson]

On Thu, Feb 18, 2016 at 8:41 AM, Igor Gnatenko
<i.gnatenko.brain(a)gmail.com&gt; wrote:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1307783
>
>  Looks like it failed on armv7 with this error, but it was working before...
>  Any ideas? 
It's an issue we see occasionally where the package thinks it knows
better than the explicit CFLAGs being set, I'll get it sorted out.

Peter

[Kevin Kofler]

Peter Robinson wrote:
>  It's an issue we see occasionally where the package thinks it
> knows
>  better than the explicit CFLAGs being set, I'll get it sorted out. 
But why are those intrinsics now requiring NEON at all? Those are GCC byte 
swap intrinsics documented as being architecture-independent and should be 
implemented in software (through shifts or rotates) when there is no native 
byte swap instruction.

And is Fedora actually requiring NEON as the baseline on ARM? I thought it 
was not.

        Kevin Kofler

[Carlos O'Donell]

On 02/18/2016 08:37 PM, Kevin Kofler wrote:
>  Peter Robinson wrote:
> > It's an issue we see occasionally where the package thinks it knows
> > better than the explicit CFLAGs being set, I'll get it sorted out.
>  
>  But why are those intrinsics now requiring NEON at all? Those are GCC byte 
>  swap intrinsics documented as being architecture-independent and should be 
>  implemented in software (through shifts or rotates) when there is no native 
>  byte swap instruction.
>  
>  And is Fedora actually requiring NEON as the baseline on ARM? I thought it 
>  was not. 
We require an ARMv7A or newer and a VFP with enough registers to support
the hard ABI e.g. -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16

The message in the header error is only an example.

Cheers,
Carlos.

[Peter Robinson]

> > Peter Robinson wrote:
> >> It's an issue we see occasionally where the package thinks it knows
> >> better than the explicit CFLAGs being set, I'll get it sorted out.
> >
> > But why are those intrinsics now requiring NEON at all? Those are GCC byte
> > swap intrinsics documented as being architecture-independent and should be
> > implemented in software (through shifts or rotates) when there is no native
> > byte swap instruction.
> >
> > And is Fedora actually requiring NEON as the baseline on ARM? I thought it
> > was not.
>
>  We require an ARMv7A or newer and a VFP with enough registers to support
>  the hard ABI e.g. -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 
Correct, there is no requirement for NEON, it's optional in the ARMv7
spec. Some code looks at the HW and tries incorrectly to enable NEON
optimisation, this is incorrect code, it should be obeying the CFLAGS
passed by the compiler and if it wishes to support NEON do so with
fast paths in the code (see libpng/pixman/cairo for examples). This
isn't new to gcc6, we've seen it on and off ever since I've been
dealing with ARM architectures all the way back to (at least) gcc 4.3

Peter

[Hans de Goede]

Hi,

On 26-02-16 11:51, Peter Robinson wrote:
> >> Peter Robinson wrote:
> >>> It's an issue we see occasionally where the package thinks it knows
> >>> better than the explicit CFLAGs being set, I'll get it sorted out.
> >>
> >> But why are those intrinsics now requiring NEON at all? Those are GCC byte
> >> swap intrinsics documented as being architecture-independent and should be
> >> implemented in software (through shifts or rotates) when there is no native
> >> byte swap instruction.
> >>
> >> And is Fedora actually requiring NEON as the baseline on ARM? I thought it
> >> was not.
> >
> > We require an ARMv7A or newer and a VFP with enough registers to support
> > the hard ABI e.g. -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
>
>  Correct, there is no requirement for NEON, it's optional in the ARMv7
>  spec. Some code looks at the HW and tries incorrectly to enable NEON
>  optimisation, this is incorrect code, it should be obeying the CFLAGS
>  passed by the compiler and if it wishes to support NEON do so with
>  fast paths in the code (see libpng/pixman/cairo for examples). This
>  isn't new to gcc6, we've seen it on and off ever since I've been
>  dealing with ARM architectures all the way back to (at least) gcc 4.3 
Right I've recently fixed the same build-error in openal-soft, see:

http://pkgs.fedoraproject.org/cgit/rpms/openal-soft.git/commit/?id=9e5bf7...

Specifically what I had to do was:

-%cmake .
+%cmake -DALSOFT_CPUEXT_NEON:BOOL=OFF .

IOW I turned of the unconditional use of NEON in the code. Now with mozjs
chances are it does runtime detection and only uses the code in the
object file which tries to build when it runtime detects NEON, if that
is the case then the ideal solution would be to change the buildsys
to pass -ffpu=neon (IIRC) when building that specific object-file.

If you're unsure what to do the best thing is to just disable the use
of neon altogether like I did with openal-soft.

Regards,

Hans

[Igor Gnatenko]

Any news here? Unfortunately it's still not fixed.