<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Chris, is that the case for MacOS 10.8 as well?<div class=""><div><br class=""><div class=""></div></div><blockquote type="cite" class=""><div><div class="">On 2021-05-04-T, at 14:24, Christopher Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" class="">jonesc@hep.phy.cam.ac.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Thats very out out date. The as provided by the cctools port either uses a new LLVM build, or just wraps the Xcode tools on the most recent systems. It supports AVX just fine.</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On 4 May 2021, at 7:17 pm, Christopher Nielsen <<a href="mailto:mascguy@rochester.rr.com" class="">mascguy@rochester.rr.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Based on the following ticket, it sounds as if GCC is utilizing Apple’s assembler by default?<div class=""><br class=""></div><div class="">cctools as does not support AVX, consider using llvm: <a href="https://trac.macports.org/ticket/37846" class="">https://trac.macports.org/ticket/37846</a></div><div class=""><br class=""></div><div class="">The suggested fix - albeit from 3 years ago - requires manually selecting clang, via ‘port select’. Is that still accurate? Are there any other clean ways to fix this, apart from disabling use of AVX instructions?</div><div class=""><div class=""><div class=""><br class=""><div class=""></div><blockquote type="cite" class=""><div class="">On 2021-05-04-T, at 12:45, Christopher Nielsen <<a href="mailto:mascguy@rochester.rr.com" class="">mascguy@rochester.rr.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I’m currently reviewing the build logs for openmpi-* subports, which are failing to build for older MacOS releases.<br class=""><br class="">And it looks like the issue relates to the use of the various AVX* instruction sets:<br class=""><br class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><font face="Courier New" size="1" class="">  CCLD     <a href="http://liblocal_ops_avx2.la/" class="">liblocal_ops_avx2.la</a><br class=""><stdin>:1015:20: error: invalid operand for instruction<br class="">        vmovdqu64       (%rdi), %ymm0<br class="">                                ^~~~~<br class=""><stdin>:1019:12: error: invalid operand for instruction<br class="">        vmovdqu64       %ymm0, -32(%rsi)<br class="">                        ^~~~~<br class=""><stdin>:1127:20: error: invalid operand for instruction<br class="">        vmovdqu64       (%rdi), %ymm0<br class="">                                ^~~~~<br class=""><stdin>:1131:12: error: invalid operand for instruction<br class="">        vmovdqu64       %ymm0, -32(%rsi)<br class="">                        ^~~~~<br class="">[…etc…]</font></blockquote><br class="">We can fix the problem by disabling use of those instructions, via a configure flag. The simplest approach would be to disable them across-the-board, albeit with a slight performance penalty. Or we can add conditional logic to disable them for those older releases.<br class=""><br class="">There’s something curious though: These instructions are supported for GCC 5 and 6, on MacOS 10.8. But GCC releases from 7 on, don’t seem to. (All GCC releases are working for later MacOS releases, though.)<br class=""><br class="">So… do our GCC 7+ releases for MacOS 10.8 and earlier, not include AVX* support? If not, would it be feasible to patch them?</div></div></blockquote></div></div></div></div></div></blockquote></div></div></div></div></div></blockquote></div></body></html>