Issues with compiler flags in gfortran

[Chris Jones]

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 <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
>>>>>>
>>