Get a Mac build working about ekat HOT 10 CLOSED

This is linked to E3SM-Project/scream#484. In fact, we were ddiscussing a similar solution regarding FPE on Mac OS.

from ekat.

@pbosler The CMake solution for special-handling of Mac OS seems reasonable.

from ekat.

Thanks for opening your first issue here! Be sure to follow the issue template!

from ekat.

Floating point exception handling

Gnu has non-standard functions, e.g., feenableexcept that help with floating point exceptions; these aren't included in the Mac OS native compilers.

This CMake block identifies the problem (tested on both linux and mac --- the #cmakedefine works properly):

include(CheckSymbolExists)
check_symbol_exists(feenableexcept "fenv.h" HAVE_FEENABLEEXCEPT)
if (NOT HAVE_FEENABLEEXCEPT)
  option(EKAT_NEEDS_FEENABLEEXCEPT "compiler does not include feenableexcept." ON)
endif()

And adding these functions if the above check is true, fixes this:

static int
fegetexcept (void)
{
  static fenv_t fenv;

  return fegetenv (&fenv) ? -1 : (fenv.__control & FE_ALL_EXCEPT);
}

static int
feenableexcept (unsigned int excepts)
{
  static fenv_t fenv;
  unsigned int new_excepts = excepts & FE_ALL_EXCEPT,
               old_excepts;  // previous masks

  if ( fegetenv (&fenv) ) return -1;
  old_excepts = fenv.__control & FE_ALL_EXCEPT;

  // unmask
  fenv.__control &= ~new_excepts;
  fenv.__mxcsr   &= ~(new_excepts << 7);

  return ( fesetenv (&fenv) ? -1 : old_excepts );
}

static int
fedisableexcept (unsigned int excepts)
{
  static fenv_t fenv;
  unsigned int new_excepts = excepts & FE_ALL_EXCEPT,
               old_excepts;  // all previous masks

  if ( fegetenv (&fenv) ) return -1;
  old_excepts = fenv.__control & FE_ALL_EXCEPT;

  // mask
  fenv.__control |= new_excepts;
  fenv.__mxcsr   |= new_excepts << 7;

  return ( fesetenv (&fenv) ? -1 : old_excepts );
}

Note: This issue is summarized well here.
And a solution dating back to 2009 can be found here, fe-handling-example.c

The solution posted above takes only a snippet of code from fe-handling-example.c, which lists a Public Domain license. The whole code contains special cases for older Mac architectures (e.g., PPC) that we likely won't need.

from ekat.

Packs and pow

To get ekat_pack.hpp various impls of pow to work, I had to remove the explicit template parameter for std::pow, e.g.,

• Before: s[i] = std::pow<typename PackType::scalar>(a[i], b);
• After: s[i] = std::pow(a[i],b)

Explanation & details:

In the Apple version of math.h is the following impl of std::pow:

template <class _A1, class _A2>
inline _LIBCPP_INLINE_VISIBILITY
typename std::__lazy_enable_if
<
    std::is_arithmetic<_A1>::value &&
    std::is_arithmetic<_A2>::value,
    std::__promote<_A1, _A2>
>::type
pow(_A1 __lcpp_x, _A2 __lcpp_y) _NOEXCEPT
{
    typedef typename std::__promote<_A1, _A2>::type __result_type;
    static_assert((!(std::is_same<_A1, __result_type>::value &&
                     std::is_same<_A2, __result_type>::value)), "");
    return ::pow((__result_type)__lcpp_x, (__result_type)__lcpp_y);
}

The "before" lines above from ekat_pack.hpp failed the static_assert.

edit: Warning for @pbosler and @jeff-cohere : This change has not yet been tested on linux.
Tests pass on Mac, linux, with Kokkos serial.

from ekat.

constexpr and ekat::util::ScalingFactor

The constexpr constructor of ScalingFactor uses std::get<>, which is not a constexpr. Clang doesn't like this.

Note: In c++14, std::get is constexpr. Easy fix: configure with -DCMAKE_CXX_STANDARD=14

from ekat.

constexpr and ekat::util::ScalingFactor

The constexpr constructor of ScalingFactor uses std::get<>, which is not a constexpr. Clang doesn't like this.

Note: In c++14, std::get is constexpr. Easy fix: configure with -DCMAKE_CXX_STANDARD=14

We need to be more strict in our testing, and ensure that C++11 only features are allowed (no free C++14 ones). I thought that was already the case, but I guess gcc is one step ahead, and introduced some C++14 feature earlier.

I'm somewhat reluctant to require C++14. Don't get me wrong, I'd love C++14, actually I'd like C++17 and sometimes even C++20 (templated lambda, concept...). The reason I'm reluctant is the support we can expect on our target machines. IIRC, on Summit we can only rely on C++11. I'm not sure if we can count on C++14, definitely not on C++17 (cuda's not there yet, at least not with stable versions).

Some files in Ekat are precisely trying to backport some of the C++14 features (and kokkos also does that, sometimes). However, some things cannot be backported, like whether or not a function is marked constexpr in std namespace. =(

I'm not sure what the best course of action is here. Supporting Mac builds is nice, but there are no "production" mac machines, which makes me somewhat reluctant to hack our codes (sometimes removing features) just for convenience of developing on Mac. That said, a constexpr constructor for ScalingFactor is probably not necessary (I don't foresee anyone using compile-time ScalingFactor instances...), so maybe we could simply remove the constexpr keyword in these cases...

from ekat.

I just checked linux, with gcc7.3 and -DCMAKE_CXX_STANDARD=11, and everything builds and all tests pass. And since, as you say, there are no HPC Mac machines, I don't think we need to require c++14 for ekat at all --- just leave it as a note, "If you want to build on Mac, you'll need to set this cmake variable."

edit: We could have CMake do that for us : if ${CMAKE_SYSTEM_NAME} == Darwin, set CMAKE_CXX_STANDARD=14

This would leave it up to us high-maintenance Mac people to make sure that we don't use any c++14 features, but since we know EKAT only supports C++11, that seems like a reasonable cost of doing business.

In any case, I completely agree that Mac concerns should not dictate terms to an HPC project.

from ekat.

I think the fact that we build/test on a variety of non-Mac machines will likely keep us honest. But let's keep our eyes open for better workarounds.

from ekat.

Cool. I put it in #21.

from ekat.