On 22/01/2019 3:44 pm, Ken Cunningham wrote:
So this "as" issue comes up with gcc / gfortran every so often, more lately
with more attempts to use newer SIMD instruction sets that generate assembly that only
newer clangs can assemble. There are scattered tickets here and there about it over the
past few years.
One partial but very practical solution might be to make cctools an "empty
port" on systems with a new enough Xcode. After all, it offers no benefits I can see
for those systems anyway. That would cover off all current systems, sending them to Xcode
instead and is very simple to do with no variants needed, etc.
This is exactly what the xcode variant of cctools was designed to do. In
fact, a while back before the relatively recent update to cctools, when
it was based on a version of the tool kit older than that in Xcode 9 at
that time, we made the xcode variant the default on this system, to
avoid exactly the sort of issues here.
More recently, cctools was updated to a newer version of the Apple open
sourced toolkit and at that time the cctools maintainer decided to
switch the default variant for those systems back to actually building
the toolkit, instead of just wrapping the Xcode tools.
These flips in the defaults are very far from ideal, as each time we do
it we have issues with the fact default upgrades respect the previous
variants, so if we want a given port to force the switch, specific code
has to be added to the Port to do this. I in fact have a open PR to do
just this, following the last update.
https://github.com/macports/macports-ports/pull/2980
In my opinion we need to give some thought to how to handle this better,
as the current flip flopping between variants needs to be avoided. One
thing is sure, its not impossible that the same situation will rise
again and again, as newer Xcodes come along, that out date the cctools
version, or as more and more code bases use more recent CPU features
(like AVX2. AVX512 etc.).
cheers Chris
For older systems, we would ideally make "as" point to a specific clang (ie
patch the source), and then ensure that clang is installed. That seems quite easy, too.
An immediate, simple but manual workaround is to have the user "sudo port select" a current
installed clang, like clang-7.0. Then "as" would hand off to "clang-7.0" and all modern
instructions are available. Obviously not an ideal automatic solution, but a 10 second fix for a stuck user
for right now.
Patching or configuring gcc to call a specific clang directly as an assembler
seems to me to be quite complicated, but may appear simpler to some others. I
looked at this before and balked.
K
On Jan 22, 2019, at 07:07, Nicolas Pavillon <[email protected]> wrote:
The MacPorts provided as, from cctools, is *supposed* to be the same as that
provided by Xcode 10. Actually, one thing you have not said is what macOS
version are you using ?
Sure, sorry. I did not think it would be important at the time.
- Mac OS 10.14.2
- Xcode 10.1
Chris
Cheers,
Nicolas
On Jan 22, 2019, at 11:23, Chris Jones <[email protected]
<mailto:[email protected]>> wrote:
Hi,
Could you then please try either removing the cctools package, or reinstall it
with the xcode variant. Either should result in the build using the xcode
provided as instead.
Chris
On 21 Jan 2019, at 3:54 pm, Nicolas Pavillon <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I just tried that, and I think I have been using the current default:
NicolasMacBook:~ nicos$ port installed cctools
The following ports are currently installed:
cctools @921_0+llvm70 (active)
The reason I have been mentioning how old as might be is that the one provided
by cctools returns version 1.38, which quite behind compared to the version
provided by binutils, for example.
/opt/local/bin/as -v
Apple Inc version cctools-921, GNU assembler version 1.38
Cheers,
Nicolas
On Jan 22, 2019, at 0:23, Chris Jones <[email protected]
<mailto:[email protected]>> wrote:
Hi,
What exactly version (and variants) of cctools do you have installed ?
Perhaps try force removing it, then reinstall, to make sure you are using the
current default variants.
Chris
On 21 Jan 2019, at 2:47 pm, Nicolas Pavillon <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I stumbled on some issues with the fortran compiler that I cannot really
understand. They might be linked with other topics discussed recently about
cctools, but it still seems somewhat different.
This happens with the port OpenBLAS, where the compilation fails when flags to
compile AVX instructions yield errors during compilation, as described in the
following tickets:
https://trac.macports.org/ticket/57912
https://github.com/xianyi/OpenBLAS/issues/1951
However, when I tried even more basic flags such as -march=native, compilation
also fails with errors such as
/var/folders/x8/q7j02h4d661_p7cjh42_jh380000gn/T//ccqkNy6A.s:103:no such
instruction: `vxorps %xmm0, %xmm0,%xmm0'
I then tried with another gfortran compiler outside of macports, and it could
compile without any issue if I remove macports’ prefix from the path, which
seems to indicate that the issue is coming from the assembler in macports.
My best guess is that as in cctools is too old, but I am not sure about that.
Also, if it is correct, I wonder how this could be solved. Any ideas?
Cheers,
Nicolas
