>> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
