Re: assembler error on trying to port OpenBLAS
On 2020/10/30 23:14, Brad Smith wrote:
> On Fri, Oct 30, 2020 at 04:55:53PM +, Stuart Henderson wrote:
> > On 2020/10/29 20:25, Aisha Tammy wrote:
> > > I'm trying to port OpenBLAS to the tree and am currently getting
> > > some weird assembler errors (port makefile is attached at end
> > > math/openblas)
> >
> > not that weird, the source code has inline asm, it is passed to
> > /usr/bin/as which is pretty old and pre-dates support for this
> > being added
> >
> > > Presumably this is happening due to the assembler being used is
> > > the one from base as we don't build the ports egcc with gas for
> > > anything except aarch64 and arm.
> > > I'm kind of stumped here as it seems like using gfortran sets the
> > > compiler to egcc (compiling the above file with cc works).
> > > Is it possible to mix gfortran with base-clang C compiler?
> > > Another (possible) solution would be to build egcc all archs with
> > > the new gas assembler, but that sounds a lot more dangerous and I
> > > don't know enough to know if that is possible/or even a good idea/
> > > or if it will even work :-/
> >
> > I think ports/lang/gcc should start using the newer version of gas
> > from ports on i386 and amd64.
> >
> > On these archs it doesn't affect many ports (fortran things,
> > asterisk, seabios [vmm-firmware], maybe one or two others).
> >
> > For other archs there is higher risk as large parts of the ports
> > tree use ports-gcc on most of these. But there's probably less need
> > for the newer assembler on those too.
>
> I had sent a diff like the following to Pascal last year. Since in the
> past we had run into issues with inline asm and our GNU as being too old.
>
>
> Index: Makefile
> ===
> RCS file: /home/cvs/ports/lang/gcc/8/Makefile,v
> retrieving revision 1.34
> diff -u -p -u -p -r1.34 Makefile
> --- Makefile 4 Sep 2020 09:55:34 - 1.34
> +++ Makefile 31 Oct 2020 03:08:05 -
> @@ -18,6 +18,7 @@ DPB_PROPERTIES = parallel
> V = 8.4.0
> FULL_VERSION = $V
> FULL_PKGVERSION = $V
> +REVISION = 0
>
> ADASTRAP-amd64 = adastrap-amd64-8.3.0-2.tar.xz
> ADASTRAP-arm = adastrap-arm-4.9.4-0.tar.xz
> @@ -65,7 +66,8 @@ EXTRACT_ONLY = ${DISTNAME}.tar.xz
> BUILD_DEPENDS += devel/bison \
> devel/libexecinfo
>
> -.if ${MACHINE_ARCH} == "aarch64" || ${MACHINE_ARCH} == "arm"
> +.if ${MACHINE_ARCH} == "aarch64" || ${MACHINE_ARCH} == "amd64" || \
> +${MACHINE_ARCH} == "arm" || ${MACHINE_ARCH} == "i386"
> BUILD_DEPENDS += devel/gas
> RUN_DEPENDS += devel/gas
> RUN_DEPENDS-main += devel/gas
>
Committed but I have backed it out again. Turns out this fails when
linking the produced objects with ld.bfd, which is needed by at least
seabios (sysutils/firmware/vmm) on amd64/i386, and asterisk on i386
(USE_LLD=No in ports).
Re: assembler error on trying to port OpenBLAS
On Sun, Nov 01, 2020 at 07:44:18PM +, Stuart Henderson wrote: > On 2020/11/01 17:58, Dima Pasechnik wrote: > > On Sun, Nov 01, 2020 at 03:03:02PM +, Stuart Henderson wrote: > > > It is just an assembler, a newer version of the one that's already used, > > > there's not really much that's likely to go wrong, it's more likely to fix > > > than introduce problems. > > > > > > If you have some cycles to spare, building gcc with Brad's diff and > > > checking > > > that a selection of the existing ports (pcbasic, vmm-firmware, Fortran > > > things) still build with it would be useful. > > > > I don't understand why using gcc is preferred here to using clang. > > With clang and egfortran one does not need to worry about gas, as > > there is no inline assembly in Fortran code in OpenBLAS. > > Besides, it's all reasonably well-tested on a number of OS (Linux, macOS, > > FreeBSD) that it's perfectly OK to mix clang and gfortran for OpenBLAS > > (and its consumers such as numpy). > > Changing the gcc port to use a more appropriate assembler is simple to > reason about, simple to test, and fixes another problem we already have > as well as works around this one. Of course it doesn't rule out *also* > changing ports using gfortran to use clang as the C compiler later. > > Changing those to clang for C might be fine too, and I wouldn't object > to doing that if someone wants to untangle lang/8/gcc4.port.mk to > figure out how to implement it and test it (making sure that it breaks > things with neither base-clang arches nor base-gcc archs - important to > check both and that ports produced following that change still have the > correct LIB_DEPENDS/WANTLIB in both cases). Are you saying that one cannot just request clang (from ports) to be used explictly (or, say, as 1st choice) for OpenBLAS, it all has to go via a generic C compiler config? Is it because gfortran is not a really independent package, but somehow bundled with gcc (as C compiler), just because it happens to be built from the same source ? If so, wouldn't it be easier to make gfortran package (unfortunately called g95 on OpenBSD) a "real" package, rather than trying to tweak gcc? Dima
Re: assembler error on trying to port OpenBLAS
On 2020/11/01 17:58, Dima Pasechnik wrote: > On Sun, Nov 01, 2020 at 03:03:02PM +, Stuart Henderson wrote: > > It is just an assembler, a newer version of the one that's already used, > > there's not really much that's likely to go wrong, it's more likely to fix > > than introduce problems. > > > > If you have some cycles to spare, building gcc with Brad's diff and checking > > that a selection of the existing ports (pcbasic, vmm-firmware, Fortran > > things) still build with it would be useful. > > I don't understand why using gcc is preferred here to using clang. > With clang and egfortran one does not need to worry about gas, as > there is no inline assembly in Fortran code in OpenBLAS. > Besides, it's all reasonably well-tested on a number of OS (Linux, macOS, > FreeBSD) that it's perfectly OK to mix clang and gfortran for OpenBLAS > (and its consumers such as numpy). Changing the gcc port to use a more appropriate assembler is simple to reason about, simple to test, and fixes another problem we already have as well as works around this one. Of course it doesn't rule out *also* changing ports using gfortran to use clang as the C compiler later. Changing those to clang for C might be fine too, and I wouldn't object to doing that if someone wants to untangle lang/8/gcc4.port.mk to figure out how to implement it and test it (making sure that it breaks things with neither base-clang arches nor base-gcc archs - important to check both and that ports produced following that change still have the correct LIB_DEPENDS/WANTLIB in both cases).
Re: assembler error on trying to port OpenBLAS
On Sun, Nov 01, 2020 at 03:03:02PM +, Stuart Henderson wrote: > It is just an assembler, a newer version of the one that's already used, > there's not really much that's likely to go wrong, it's more likely to fix > than introduce problems. > > If you have some cycles to spare, building gcc with Brad's diff and checking > that a selection of the existing ports (pcbasic, vmm-firmware, Fortran > things) still build with it would be useful. I don't understand why using gcc is preferred here to using clang. With clang and egfortran one does not need to worry about gas, as there is no inline assembly in Fortran code in OpenBLAS. Besides, it's all reasonably well-tested on a number of OS (Linux, macOS, FreeBSD) that it's perfectly OK to mix clang and gfortran for OpenBLAS (and its consumers such as numpy). Dima > > -- > Sent from a phone, apologies for poor formatting. > On 1 November 2020 14:03:28 Aisha Tammy wrote: > > > On 11/1/20 8:49 AM, Stuart Henderson wrote: > > > On 2020/10/31 23:33, Aisha Tammy wrote: > > > > > But that's not an option for something that is to be commited to the > > > > > tree. > > > > > > > > > > > > > Well damn... > > > > Is there any other method to fix the compiler to cc instead of > > > > this? > > > > I tried adding the lang/clang module before the fortran module > > > > MODULES = lang/clang fortran > > > > but that fixes the compiler to /usr/local/bin/clang instead of the > > > > /usr/bin/clang. > > > > I am not sure what else to try right now :( > > > > > > The correct fix IMHO is the diff that Brad sent for ports/lang/gcc as > > > this not only fixes this, but fixes some other problems we run into > > > from time to time. > > > > > > If there is some other idea of using a different C compiler for ports > > > which mix fortran+C then that should be handled in fortran ports modules > > > or other infrastructure rather than individual ports. > > > > > > > That sounds good to me! > > I assume there is going to be testing needed for getting > > gas+egcc in the tree first. > > In that case, I will pause my work on OpenBLAS until it > > is incorporated. There is just way too much assembly in > > OpenBLAS to do any considerable testing and switching it > > to a different compiler later on. > > > > Current port (with half-assed patching copied from gentoo) > > link for anyone who wants to keep trying - > > https://github.com/epsilon-0/openbsd-ports/tree/openblas/math/openblas > > > > Best, > > Aisha >
Re: assembler error on trying to port OpenBLAS
It is just an assembler, a newer version of the one that's already used, there's not really much that's likely to go wrong, it's more likely to fix than introduce problems. If you have some cycles to spare, building gcc with Brad's diff and checking that a selection of the existing ports (pcbasic, vmm-firmware, Fortran things) still build with it would be useful. -- Sent from a phone, apologies for poor formatting. On 1 November 2020 14:03:28 Aisha Tammy wrote: On 11/1/20 8:49 AM, Stuart Henderson wrote: On 2020/10/31 23:33, Aisha Tammy wrote: But that's not an option for something that is to be commited to the tree. Well damn... Is there any other method to fix the compiler to cc instead of this? I tried adding the lang/clang module before the fortran module MODULES = lang/clang fortran but that fixes the compiler to /usr/local/bin/clang instead of the /usr/bin/clang. I am not sure what else to try right now :( The correct fix IMHO is the diff that Brad sent for ports/lang/gcc as this not only fixes this, but fixes some other problems we run into from time to time. If there is some other idea of using a different C compiler for ports which mix fortran+C then that should be handled in fortran ports modules or other infrastructure rather than individual ports. That sounds good to me! I assume there is going to be testing needed for getting gas+egcc in the tree first. In that case, I will pause my work on OpenBLAS until it is incorporated. There is just way too much assembly in OpenBLAS to do any considerable testing and switching it to a different compiler later on. Current port (with half-assed patching copied from gentoo) link for anyone who wants to keep trying - https://github.com/epsilon-0/openbsd-ports/tree/openblas/math/openblas Best, Aisha
Re: assembler error on trying to port OpenBLAS
On 11/1/20 8:49 AM, Stuart Henderson wrote: On 2020/10/31 23:33, Aisha Tammy wrote: But that's not an option for something that is to be commited to the tree. Well damn... Is there any other method to fix the compiler to cc instead of this? I tried adding the lang/clang module before the fortran module MODULES = lang/clang fortran but that fixes the compiler to /usr/local/bin/clang instead of the /usr/bin/clang. I am not sure what else to try right now :( The correct fix IMHO is the diff that Brad sent for ports/lang/gcc as this not only fixes this, but fixes some other problems we run into from time to time. If there is some other idea of using a different C compiler for ports which mix fortran+C then that should be handled in fortran ports modules or other infrastructure rather than individual ports. That sounds good to me! I assume there is going to be testing needed for getting gas+egcc in the tree first. In that case, I will pause my work on OpenBLAS until it is incorporated. There is just way too much assembly in OpenBLAS to do any considerable testing and switching it to a different compiler later on. Current port (with half-assed patching copied from gentoo) link for anyone who wants to keep trying - https://github.com/epsilon-0/openbsd-ports/tree/openblas/math/openblas Best, Aisha
Re: assembler error on trying to port OpenBLAS
On 2020/10/31 23:33, Aisha Tammy wrote: > > But that's not an option for something that is to be commited to the tree. > > > > Well damn... > Is there any other method to fix the compiler to cc instead of > this? > I tried adding the lang/clang module before the fortran module > MODULES = lang/clang fortran > but that fixes the compiler to /usr/local/bin/clang instead of the > /usr/bin/clang. > I am not sure what else to try right now :( The correct fix IMHO is the diff that Brad sent for ports/lang/gcc as this not only fixes this, but fixes some other problems we run into from time to time. If there is some other idea of using a different C compiler for ports which mix fortran+C then that should be handled in fortran ports modules or other infrastructure rather than individual ports.
Re: assembler error on trying to port OpenBLAS
On 2020/10/31 12:57, Aisha Tammy wrote: > > Thanks for the people who commented. > I've managed to fix the error by forcing the > COMPILER_LINKS = cc /usr/bin/cc gcc /usr/bin/gcc OK as a quick workaround hack to get you un-stuck, but this is not good for commit ;)
Re: assembler error on trying to port OpenBLAS
On Sat, Oct 31, 2020 at 11:33:07PM -0400, Aisha Tammy wrote: > On 10/31/20 9:48 PM, Brad Smith wrote: > > On 10/31/2020 12:57 PM, Aisha Tammy wrote: > > > On 10/29/20 8:25 PM, Aisha Tammy wrote: > > > > Hi, > > > > I'm trying to port OpenBLAS to the tree and am currently getting > > > > some weird assembler errors (port makefile is attached at end > > > > math/openblas) > > > > > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages: > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such instruction: > > > > `vbroadcastss (%rcx),%ymm0' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such instruction: > > > > `vmovups (%rdx,%rax,4),%ymm8' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such instruction: > > > > `vmovups 32(%rdx,%rax,4),%ymm9' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such instruction: > > > > `vmovups 64(%rdx,%rax,4),%ymm10' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such instruction: > > > > `vmovups 96(%rdx,%rax,4),%ymm11' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such instruction: > > > > `vmovups (%rsi,%rax,4),%ymm4' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such instruction: > > > > `vmovups 32(%rsi,%rax,4),%ymm5' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such instruction: > > > > `vmovups 64(%rsi,%rax,4),%ymm6' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such instruction: > > > > `vmovups 96(%rsi,%rax,4),%ymm7' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such instruction: > > > > `vmulps %ymm4,%ymm0,%ymm4' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such instruction: > > > > `vaddps %ymm8,%ymm4,%ymm12' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such instruction: > > > > `vmulps %ymm5,%ymm0,%ymm5' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such instruction: > > > > `vaddps %ymm9,%ymm5,%ymm13' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such instruction: > > > > `vmulps %ymm6,%ymm0,%ymm6' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such instruction: > > > > `vaddps %ymm10,%ymm6,%ymm14' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such instruction: > > > > `vmulps %ymm7,%ymm0,%ymm7' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such instruction: > > > > `vaddps %ymm11,%ymm7,%ymm15' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such instruction: > > > > `vmovups (%rdx,%rax,4),%ymm8' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such instruction: > > > > `vmovups 32(%rdx,%rax,4),%ymm9' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such instruction: > > > > `vmovups 64(%rdx,%rax,4),%ymm10' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such instruction: > > > > `vmovups 96(%rdx,%rax,4),%ymm11' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such instruction: > > > > `vmovups (%rsi,%rax,4),%ymm4' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such instruction: > > > > `vmovups 32(%rsi,%rax,4),%ymm5' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such instruction: > > > > `vmovups 64(%rsi,%rax,4),%ymm6' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such instruction: > > > > `vmovups 96(%rsi,%rax,4),%ymm7' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such instruction: > > > > `vmovups %ymm12,-128(%rdx,%rax,4)' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such instruction: > > > > `vmovups %ymm13,-96(%rdx,%rax,4)' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such instruction: > > > > `vmovups %ymm14,-64(%rdx,%rax,4)' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such instruction: > > > > `vmovups %ymm15,-32(%rdx,%rax,4)' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such instruction: > > > > `vmulps %ymm4,%ymm0,%ymm4' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such instruction: > > > > `vmulps %ymm5,%ymm0,%ymm5' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such instruction: > > > > `vmulps %ymm6,%ymm0,%ymm6' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such instruction: > > > > `vmulps %ymm7,%ymm0,%ymm7' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such instruction: > > > > `vaddps %ymm8,%ymm4,%ymm12' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such instruction: > > > > `vaddps %ymm9,%ymm5,%ymm13' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such instruction: > > > > `vaddps %ymm10,%ymm6,%ymm14' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such instruction: > > > > `vaddps %ymm11,%ymm7,%ymm15' > > > > ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such instruction: > > > > `vmovups %ymm12,-128(%rdx,%rax,4)' > > > >
Re: assembler error on trying to port OpenBLAS
On 10/31/20 9:48 PM, Brad Smith wrote: On 10/31/2020 12:57 PM, Aisha Tammy wrote: On 10/29/20 8:25 PM, Aisha Tammy wrote: Hi, I'm trying to port OpenBLAS to the tree and am currently getting some weird assembler errors (port makefile is attached at end math/openblas) ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages: ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such instruction: `vbroadcastss (%rcx),%ymm0' ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:84: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:85: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:86: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:87: Error: no such instruction: `vzeroupper ' Presumably this is happening due to the assembler being used is the one from base as we don't build the ports egcc with gas for anything except aarch64 and arm. I'm kind of stumped here as it seems like using gfortran sets the compiler to egcc (compiling the above file with cc works). Is it possible to mix gfortran with
Re: assembler error on trying to port OpenBLAS
On 10/31/2020 12:57 PM, Aisha Tammy wrote: On 10/29/20 8:25 PM, Aisha Tammy wrote: Hi, I'm trying to port OpenBLAS to the tree and am currently getting some weird assembler errors (port makefile is attached at end math/openblas) ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages: ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such instruction: `vbroadcastss (%rcx),%ymm0' ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:84: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:85: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:86: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:87: Error: no such instruction: `vzeroupper ' Presumably this is happening due to the assembler being used is the one from base as we don't build the ports egcc with gas for anything except aarch64 and arm. I'm kind of stumped here as it seems like using gfortran sets the compiler to egcc (compiling the above file with cc works). Is it possible to mix gfortran with base-clang C compiler? Another (possible)
Re: assembler error on trying to port OpenBLAS
On 10/29/20 8:25 PM, Aisha Tammy wrote: Hi, I'm trying to port OpenBLAS to the tree and am currently getting some weird assembler errors (port makefile is attached at end math/openblas) ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages: ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such instruction: `vbroadcastss (%rcx),%ymm0' ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:84: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:85: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:86: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:87: Error: no such instruction: `vzeroupper ' Presumably this is happening due to the assembler being used is the one from base as we don't build the ports egcc with gas for anything except aarch64 and arm. I'm kind of stumped here as it seems like using gfortran sets the compiler to egcc (compiling the above file with cc works). Is it possible to mix gfortran with base-clang C compiler? Another (possible) solution would be to build egcc all archs with
Re: assembler error on trying to port OpenBLAS
On Fri, Oct 30, 2020 at 04:55:53PM +, Stuart Henderson wrote:
> On 2020/10/29 20:25, Aisha Tammy wrote:
> > I'm trying to port OpenBLAS to the tree and am currently getting
> > some weird assembler errors (port makefile is attached at end math/openblas)
>
> not that weird, the source code has inline asm, it is passed to
> /usr/bin/as which is pretty old and pre-dates support for this
> being added
>
> > Presumably this is happening due to the assembler being used is
> > the one from base as we don't build the ports egcc with gas for
> > anything except aarch64 and arm.
> > I'm kind of stumped here as it seems like using gfortran sets the
> > compiler to egcc (compiling the above file with cc works).
> > Is it possible to mix gfortran with base-clang C compiler?
> > Another (possible) solution would be to build egcc all archs with
> > the new gas assembler, but that sounds a lot more dangerous and I
> > don't know enough to know if that is possible/or even a good idea/
> > or if it will even work :-/
>
> I think ports/lang/gcc should start using the newer version of gas
> from ports on i386 and amd64.
>
> On these archs it doesn't affect many ports (fortran things,
> asterisk, seabios [vmm-firmware], maybe one or two others).
>
> For other archs there is higher risk as large parts of the ports
> tree use ports-gcc on most of these. But there's probably less need
> for the newer assembler on those too.
I had sent a diff like the following to Pascal last year. Since in the
past we had run into issues with inline asm and our GNU as being too old.
Index: Makefile
===
RCS file: /home/cvs/ports/lang/gcc/8/Makefile,v
retrieving revision 1.34
diff -u -p -u -p -r1.34 Makefile
--- Makefile4 Sep 2020 09:55:34 - 1.34
+++ Makefile31 Oct 2020 03:08:05 -
@@ -18,6 +18,7 @@ DPB_PROPERTIES = parallel
V = 8.4.0
FULL_VERSION = $V
FULL_PKGVERSION = $V
+REVISION = 0
ADASTRAP-amd64 = adastrap-amd64-8.3.0-2.tar.xz
ADASTRAP-arm = adastrap-arm-4.9.4-0.tar.xz
@@ -65,7 +66,8 @@ EXTRACT_ONLY =${DISTNAME}.tar.xz
BUILD_DEPENDS += devel/bison \
devel/libexecinfo
-.if ${MACHINE_ARCH} == "aarch64" || ${MACHINE_ARCH} == "arm"
+.if ${MACHINE_ARCH} == "aarch64" || ${MACHINE_ARCH} == "amd64" || \
+${MACHINE_ARCH} == "arm" || ${MACHINE_ARCH} == "i386"
BUILD_DEPENDS += devel/gas
RUN_DEPENDS += devel/gas
RUN_DEPENDS-main +=devel/gas
Re: assembler error on trying to port OpenBLAS
On 2020/10/29 20:25, Aisha Tammy wrote: > I'm trying to port OpenBLAS to the tree and am currently getting > some weird assembler errors (port makefile is attached at end math/openblas) not that weird, the source code has inline asm, it is passed to /usr/bin/as which is pretty old and pre-dates support for this being added > Presumably this is happening due to the assembler being used is > the one from base as we don't build the ports egcc with gas for > anything except aarch64 and arm. > I'm kind of stumped here as it seems like using gfortran sets the > compiler to egcc (compiling the above file with cc works). > Is it possible to mix gfortran with base-clang C compiler? > Another (possible) solution would be to build egcc all archs with > the new gas assembler, but that sounds a lot more dangerous and I > don't know enough to know if that is possible/or even a good idea/ > or if it will even work :-/ I think ports/lang/gcc should start using the newer version of gas from ports on i386 and amd64. On these archs it doesn't affect many ports (fortran things, asterisk, seabios [vmm-firmware], maybe one or two others). For other archs there is higher risk as large parts of the ports tree use ports-gcc on most of these. But there's probably less need for the newer assembler on those too.
Re: assembler error on trying to port OpenBLAS
On Thu, Oct 29, 2020 at 08:25:05PM -0400, Aisha Tammy wrote: > I'm trying to port OpenBLAS to the tree and am currently getting > some weird assembler errors (port makefile is attached at end math/openblas) [...] > > Presumably this is happening due to the assembler being used is > the one from base as we don't build the ports egcc with gas for > anything except aarch64 and arm. > I'm kind of stumped here as it seems like using gfortran sets the > compiler to egcc (compiling the above file with cc works). > Is it possible to mix gfortran with base-clang C compiler? it is certainly possible to build OpenBLAS with clang as C compiler and gfortran as Fortran compiler. Not sure how to do this using OpenBLAS port machinery, but CC=clang FC=egfortran cmake && gmake && gmake test works for me on 6.7. It seems that clang's llvm assembler is used in such a configuration. (I suppose egfortran is installed as a part of g95 package, and provides gfortran 8.3) Hope this helps. Dima [...]
assembler error on trying to port OpenBLAS
Hi, I'm trying to port OpenBLAS to the tree and am currently getting some weird assembler errors (port makefile is attached at end math/openblas) ../kernel/x86_64/saxpy_microk_sandy-2.c: Assembler messages: ../kernel/x86_64/saxpy_microk_sandy-2.c:37: Error: no such instruction: `vbroadcastss (%rcx),%ymm0' ../kernel/x86_64/saxpy_microk_sandy-2.c:38: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:39: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:40: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:41: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:42: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:43: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:44: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:45: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:51: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:52: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:53: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:54: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:55: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:56: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:57: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:58: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:59: Error: no such instruction: `vmovups (%rdx,%rax,4),%ymm8' ../kernel/x86_64/saxpy_microk_sandy-2.c:60: Error: no such instruction: `vmovups 32(%rdx,%rax,4),%ymm9' ../kernel/x86_64/saxpy_microk_sandy-2.c:61: Error: no such instruction: `vmovups 64(%rdx,%rax,4),%ymm10' ../kernel/x86_64/saxpy_microk_sandy-2.c:62: Error: no such instruction: `vmovups 96(%rdx,%rax,4),%ymm11' ../kernel/x86_64/saxpy_microk_sandy-2.c:63: Error: no such instruction: `vmovups (%rsi,%rax,4),%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:64: Error: no such instruction: `vmovups 32(%rsi,%rax,4),%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:65: Error: no such instruction: `vmovups 64(%rsi,%rax,4),%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:66: Error: no such instruction: `vmovups 96(%rsi,%rax,4),%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:67: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:68: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:69: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:70: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:75: Error: no such instruction: `vmulps %ymm4,%ymm0,%ymm4' ../kernel/x86_64/saxpy_microk_sandy-2.c:76: Error: no such instruction: `vmulps %ymm5,%ymm0,%ymm5' ../kernel/x86_64/saxpy_microk_sandy-2.c:77: Error: no such instruction: `vmulps %ymm6,%ymm0,%ymm6' ../kernel/x86_64/saxpy_microk_sandy-2.c:78: Error: no such instruction: `vmulps %ymm7,%ymm0,%ymm7' ../kernel/x86_64/saxpy_microk_sandy-2.c:79: Error: no such instruction: `vaddps %ymm8,%ymm4,%ymm12' ../kernel/x86_64/saxpy_microk_sandy-2.c:80: Error: no such instruction: `vaddps %ymm9,%ymm5,%ymm13' ../kernel/x86_64/saxpy_microk_sandy-2.c:81: Error: no such instruction: `vaddps %ymm10,%ymm6,%ymm14' ../kernel/x86_64/saxpy_microk_sandy-2.c:82: Error: no such instruction: `vaddps %ymm11,%ymm7,%ymm15' ../kernel/x86_64/saxpy_microk_sandy-2.c:83: Error: no such instruction: `vmovups %ymm12,-128(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:84: Error: no such instruction: `vmovups %ymm13,-96(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:85: Error: no such instruction: `vmovups %ymm14,-64(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:86: Error: no such instruction: `vmovups %ymm15,-32(%rdx,%rax,4)' ../kernel/x86_64/saxpy_microk_sandy-2.c:87: Error: no such instruction: `vzeroupper ' Presumably this is happening due to the assembler being used is the one from base as we don't build the ports egcc with gas for anything except aarch64 and arm. I'm kind of stumped here as it seems like using gfortran sets the compiler to egcc (compiling the above file with cc works). Is it possible to mix gfortran with base-clang C compiler? Another (possible) solution would be to build egcc all archs with the new gas assembler, but that sounds a
