Support for OSX

Implements #364 (closed). We:

• Detect whether the POSIX library implements the barriers or not.
• If they are implemented define the SWIFT barriers as the POSIX ones.
• If not use an alternative, simple, implementation.
• Be verbose about the implementation being used.
• Update the autotools macro that sets pthread flags to the latest version. Should handle OSX in a better way.
• Detect whether FPEs can be raised on this system and set the appropriate macro.
• Update the INSTALL.swift with instructions for OSX.
• Detect Skylake (mobile and desktop) and set the appropriate architecture flags.
• Fix the dump and logger tests to write unique files to /tmp/ and delete them once done.

@jborrow could you check whether this allows SWIFT to run on your OSX machine ?

Added 2 commits:

• 77cb85ee - Updated the ax_pthread autotools macro to the latest version. Better support for clang.
• cd218003 - Check whether feenableexcept() exists before using it.

Title changed from Alternative pthread_barrier for platforms where POSIX don't provide them to Support for OSX

@jborrow did the updated autotools stuff improve things?

It solves my issues in main.c (still need to comment out dump.c though), however I also still get errors in the linking process because of the -pthread, I have to manually edit the makefiles each time and remove it.

Not addressed the dump.c issue yet. Did you run an autoreconf first ? That should, in principle, have fixed the -pthread issue.

Actually, looks like we'll need a bit more. Apparently, you can't compile with autotools, pthread and -Werror with clang on OSX. So the only option, in this case, is to remove the -Werror flag.

https://lists.gnu.org/archive/html/autoconf-archive-maintainers/2016-01/msg00005.html

That's a workaround to fix the badly conforming compiler.

Is it possible to use a newer version of clang on your machine ? Looks like the pthread behaviour has been worked on in newer releases.

Or could you try configuring with --enable-compiler-warnings ?

I'm afraid I'm stuck with LLVM 4.x... as that's what the gods at Apple have graciously provided us. However, running:

./configure --disable-compiler-warnings --disable-vec

allows me to compile with only the changes to dump.c.

Added 1 commit:

• 9d19e581 - Added information about using SWIFT on Apple devices as well as wrapping dump.c …

Ok, thanks.

We'll go with that then. I'll do a similar fix for dump.c and then document that this extra option is needed for compilation on Darwin. I guess people will have to read the readme.

For the moment I've just wrapped dump.c in an ifndef __APPLE__ but I presume you will be able to get something a little nicer working.

Yes, exactly but detected correctly by the autotools. And then do things similarly to our treatment of mpi when absent.

Added 5 commits:

• ec354705 - Also detect whether the current POSIX implementation offers the optional functio…
• 05c1e1c0 - Make the unit tests ignore FPEs if we can't activate them on this platform. Do n…
• 53a8b8e1 - Make the logger and dump tests use unique filenames in /tmp/ and remove the files upon completion.
• 0a92412e - Merge branch 'pthread_barrier' of gitlab.cosma.dur.ac.uk:swift/swiftsim into pthread_barrier
• b4ee1bf7 - Corrected merge mistake.

That should do the trick now. One last thing I would like to understand is why the vectorization needs to be disabled.

Could you provide me with the compiler error you get if you configure only with ./configure --enable-compiler-warnings ?

@jborrow have you had a chance to try it?

runner_doiact_vec.c:495:16: error: always_inline function '_mm256_fmadd_ps' requires target feature 'fma', but would be inlined into function 'runner_doself1_density_vec' that is compiled without support for 'fma'
      v_r2.v = vec_fma(v_dy.v, v_dy.v, v_r2.v);
               ^
./vector.h:237:26: note: expanded from macro 'vec_fma'
#define vec_fma(a, b, c) _mm256_fmadd_ps(a, b, c)
                         ^```

Sorry this took so long and thanks for reminding me... I have been doing my homework...

No pressure, homeworks are more important (or so I should say in public).

So, somehow the configuration script has detected that AVX2 can be used but failed to understand that you also have FMAs. Could you email me the config.h file that was generated by the configuration script?

Could you try with ./configure --enable-compiler-warnings CFLAGS="-mfma" ?