locutusofborg at debian.org
Sun Nov 6 15:22:39 UTC 2016
>So I think this should go back to RC and be fixed for stretch. BTW I think
>Gianfranco had a patch for this, maybe he can attach it here.
well, my patch wasn't good enough, but seems that somebody else gave me a better
patch to check/test.
Unfortunately after two days, harris is still building it
@@ -75,7 +75,7 @@ ARM_ARCH("armv6kz", AK_ARMV6KZ, "6KZ", "
ARM_ARCH("armv6-m", AK_ARMV6M, "6-M", "v6m", ARMBuildAttrs::CPUArch::v6_M,
ARM_ARCH("armv7-a", AK_ARMV7A, "7-A", "v7", ARMBuildAttrs::CPUArch::v7,
- FK_NEON, ARM::AEK_DSP)
+ FK_VFPV3_D16, ARM::AEK_DSP)
ARM_ARCH("armv7-r", AK_ARMV7R, "7-R", "v7r", ARMBuildAttrs::CPUArch::v7,
FK_NONE, (ARM::AEK_HWDIV | ARM::AEK_DSP))
ARM_ARCH("armv7-m", AK_ARMV7M, "7-M", "v7m", ARMBuildAttrs::CPUArch::v7,
doko said on #-release that gcc defaults to v3_d16, so I did the same (if
I did it correctly)
>Well, this is the same issue as SSE2 for i386. I would like to avoid
>penalizing performances the whole population using
>this arch just for a small percentage...
>As example, two projects focusing on performance (Firefox and Chrome)
>made that call.
>Do we have a clue how many armhf systems don't have NEON?
if gcc can't support it, llvm shouldn't do it too.
I think we can reconsider this for Buster, but for Stretch
the list of architectures is known already, I would prefer to avoid differences
with gcc, and specially because llvm-3.7 had it disabled, so this isn't
a regression to me.
>The patch has not been tested. We are not sure we can force NEON with
the build is ongoing on harris, but I think a default can't prevent
people from using better and higher features.
it is at 43% right now, and I honestly don't know how to test it
(maybe in a qemu-chroot, I'll when the build is over)
>> BTW on an unrelated note, llvm-toolchain-3.6 is out of testing!
thanks also to lowering this bug severity :)
More information about the Pkg-llvm-team