Issues with compiler flags in gfortran

[Ken Cunningham]

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.

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 <nicos at macports.org> 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 <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> 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 <nicos at macports.org <mailto:nicos at macports.org>> 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 <jonesc at hep.phy.cam.ac.uk <mailto:jonesc at hep.phy.cam.ac.uk>> 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 <nicos at macports.org <mailto:nicos at macports.org>> 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 
>>>>> 
>