On Tue, Aug 4, 2020 at 8:14 AM Dominique Martinet <asmadeus@xxxxxxxxxxxxx> wrote: > > Hi, > > this is more of a head's up than a bug per se (well, I'm actually not > sure if it's a bug, is it?), but I've had a package fail to build due to > LTO and neon optimisations: > https://kojipkgs.fedoraproject.org//work/tasks/2576/48362576/build.log > > Basically what they do is compile different .a with different level of > optimisations as required, and then link them into the final program > without any optim flag and intend to have it just use the optimised > functions as is. > > Without LTO, this just embeds the code so the rest of the program was > built naively and it used to work, but with LTO the compiler tries to > use neon optimisations at some point apparently and the link fails : > > /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/arm_neon.h:10426:22: fatal error: You must enable NEON instructions (e.g. ‘-mfloat-abi=softfp’ ‘-mfpu=neon’) to use these intrinsics. > > > The "fix" here is simple and upstream is reactive so I'll just resubmit > the package with -mfpu=neon appended to linker args as well, but this > might come bite other projects as well. NO! That is not the fix. We explicitly don't build with NEON on armhfp because there are ARMv7 processors that don't have NEON and that would then crash on those devices. I believe this is actually a bug in the waypipe project where it's trying to optimise for the processor is compiling on, not what the tool chain is telling it to because the the final binary may not run on the build processor. On aarch64/ARMv8 it can be assumed there's NEON because it's a required part of the standard, but it's not a requirement for ARMv7 processors so the software should do run time detection / fast path code to optimise if it detects NEON at runtime NOT compile time. So the bug report upstream needs to be about honoring what the compiler flags is asking it to do not what it thinks it should do. > I don't think gcc can intuite this so it's probably not a bug though > (hence I'm not planning on opening a bug), but it is a regression of > sort... You're wrong. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
