#define __local prevents compilation with macOS SDK 14

[cyrilcourvoisier]

In the file 'astc_encode_kernel.h' is defined a macro __local:

#define __kernel
#define __global
#define __constant          const
#define __local             const

#include "stdio.h"
#include <math.h>
#include <algorithm>    // std::max

The problem is that identifiers beginning with __ are reserved for the compiler. In the macOS SDK 14 (I didn't have issues with previous versions), __local is used in the <algorithm> standard header. Here is an exemple:

template <class _InIter, class _OutIter, __enable_if_t<__is_segmented_iterator<_InIter>::value, int> = 0>
  _LIBCPP_HIDE_FROM_ABI _LIBCPP_CONSTEXPR_SINCE_CXX14 pair<_InIter, _OutIter>
  operator()(_InIter __first, _InIter __last, _OutIter __result) const {
    using _Traits = __segmented_iterator_traits<_InIter>;
    auto __sfirst = _Traits::__segment(__first);
    auto __slast  = _Traits::__segment(__last);
    if (__sfirst == __slast) {
      auto __iters =
          std::__copy_backward<_AlgPolicy>(_Traits::__local(__first), _Traits::__local(__last), std::move(__result));
      return std::make_pair(__last, __iters.second);
    }

    __result =
        std::__copy_backward<_AlgPolicy>(_Traits::__begin(__slast), _Traits::__local(__last), std::move(__result))
            .second;
    --__slast;
    while (__sfirst != __slast) {
      __result =
          std::__copy_backward<_AlgPolicy>(_Traits::__begin(__slast), _Traits::__end(__slast), std::move(__result))
              .second;
      --__slast;
    }
    __result = std::__copy_backward<_AlgPolicy>(_Traits::__local(__first), _Traits::__end(__slast), std::move(__result))
                   .second;
    return std::make_pair(__last, std::move(__result));
  }

As #define __local is defined before #include , this cause _Traits::__local to be replaced by _Traits::const, causing a compilation error.
__local is not even used anywhere.

[denislevesqueAMD]

@cyrilcourvoisier Good catch! It looks like we can just remove the __local definition.

[NavNTCMP]

@cyrilcourvoisier Issue addressed in v4.5 release