GH-49371: [CI][R] Fix C++ 20 build error on macOS

[Anakin100100]

Rationale for this change

When the PR that migrates to C++ 20 stdlib bit utilities was merged the cran build came clean as seen here while afterwards the build started failing on macOS. This suggests that there was some change/regression in cran.

What changes are included in this PR?

I added a one line change in the Readme to enable making the pr, this will be removed later, this pr is the work area for fixing the cran build.

Are these changes tested?

No

Are there any user-facing changes?

No

• GitHub Issue: [C++]: Work around bit_width not being available on MacOS's partially compatible C++20 build #49371

[github-actions]

⚠️ GitHub issue #49371 has been automatically assigned in GitHub to PR creator.

[Anakin100100]

@github-actions crossbow submit cran

[github-actions]

Only contributors can submit requests to this bot. Please ask someone from the community for help with getting the first commit in.
The Archery job run can be found at: https://github.com/apache/arrow/actions/runs/22410310567

[Anakin100100]

@pitrou Can you give me access to run github actions commands with the cran build? I'd like to reproduce the issue and fix it if possible. Unfortunately I don't own a mac so can reproduce it locally.

[pitrou]

@Anakin100100 I don't think we can easily give access like that (@kou @raulcd might know more), but I can run the commands for you in the meantime.

[pitrou]

@github-actions crossbow submit cran

[github-actions]

Unable to match any tasks for `cran`
The Archery job run can be found at: https://github.com/apache/arrow/actions/runs/22410458232

[pitrou]

@github-actions crossbow submit cran

[github-actions]

Revision: fc621ad

Submitted crossbow builds: ursacomputing/crossbow @ actions-ac497c3594

Task	Status
test-r-alpine-linux-cran
test-r-linux-as-cran
test-r-macos-as-cran

[raulcd]

I don't think we can easily give access like that

Only collaborators and committers are able to trigger the bot commands currently.

[Anakin100100]

Notes

The compiler used on the failed macOS build is AppleClang 17.0.0.17000013, as per the C++ docs the bit operations in stdlib should be fully supported since Xcode 13.0.0 which was released in September 2021. On the other hand The Xcode docs don't mention any specific verions of Xcode for the two ISO C++ committee designs for this utility set P0556R3 P1956R1. I'm not sure if the empty field on the right side means that a feature is supported in all supported Xcode versions or that it means that it isn't supported in any versions.

I think I'd lean towards the interpretation that this isn't supported at all. As an example [C++17 compatibility docs] (https://en.cppreference.com/w/cpp/compiler_support/17.html) mention that Apple Clang doesn't support P0040R3 and this field is empty inside of the Apple Clang docs.

When we look at the clean run it was "using C++ compiler: ‘Apple clang version 17.0.0 (clang-1700.0.13.5)’" so the version is almost identical. Unfortunately Apple doesn't publish specific version releases outside of XCode so I can't find when either of them were released on their own.

What is interesting is that the one that failed uses MacOSX11.3.sdk from April 2021 while the one that succeeded uses MacOSX15.5.sdk from May of 2025. Macos 11.3 has reached end of life in September of 2023. It looks like inside the successful job the M1 build that uses the 15.5 sdk succeeds.

Conclusion

I'd recommend updating macOS version to 15.5 and for both the M1 and X86 cran jobs. I don't think that the Cran compatibility with MacOS version that was released 5 years ago is reasonable and will cause more similar issues in the future.

Alternatively if it's not feasible to update the macOS version that far we could still maintain compatibility with the lowest supported R for macos version 11.4 while updating to Xcode as did the R project "This release uses Xcode 16.2(arm64)/14.2(x86_64) and GNU Fortran 14.2...." to version 14.2 which was released in December of 2022 which would also probably resolve this issue.

[pitrou]

I'll let @jonkeane comment on what is possible.

[jonkeane]

Conclusion
I'd recommend updating macOS version to 15.5 and for both the M1 and X86 cran jobs. I don't think that the Cran compatibility with MacOS version that was released 5 years ago is reasonable and will cause more similar issues in the future.

Alternatively if it's not feasible to update the macOS version that far we could still maintain compatibility with the lowest supported R for macos version 11.4 while updating to Xcode as did the R project "This release uses Xcode 16.2(arm64)/14.2(x86_64) and GNU Fortran 14.2...." to version 14.2 which was released in December of 2022 which would also probably resolve this issue.

We do not control the CRAN infrastructure and upgrading (or asking to upgrade) is not feasible (or in the case of asking, worth the effort). Until they upgrade, we must find a way to build cleanly with the SDK that they have on their runners.

[kou]

It seems that std::log2p1() is used in macOS SDK 11.3:

// -*- C++ -*-
//===------------------------------ bit ----------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===---------------------------------------------------------------------===//

#ifndef _LIBCPP_BIT
#define _LIBCPP_BIT

/*
    bit synopsis

namespace std {

  // [bit.pow.two], integral powers of 2
  template <class T>
    constexpr bool ispow2(T x) noexcept; // C++20
  template <class T>
    constexpr T ceil2(T x);              // C++20
  template <class T>
    constexpr T floor2(T x) noexcept;    // C++20
  template <class T>
    constexpr T log2p1(T x) noexcept;    // C++20

  // [bit.rotate], rotating
  template<class T>
    constexpr T rotl(T x, unsigned int s) noexcept; // C++20
  template<class T>
    constexpr T rotr(T x, unsigned int s) noexcept; // C++20

  // [bit.count], counting
  template<class T>
    constexpr int countl_zero(T x) noexcept;  // C++20
  template<class T>
    constexpr int countl_one(T x) noexcept;   // C++20
  template<class T>
    constexpr int countr_zero(T x) noexcept;  // C++20
  template<class T>
    constexpr int countr_one(T x) noexcept;   // C++20
  template<class T>
    constexpr int popcount(T x) noexcept;     // C++20

  // [bit.endian], endian
  enum class endian {
    little = see below,        // C++20
    big = see below,           // C++20
    native = see below         // C++20
};

} // namespace std

*/
// ...

It seems that __cpp_lib_bitops isn't defined in macOS SDK 11.3. Can we use this?

diff --git a/cpp/src/arrow/util/bit_util.h b/cpp/src/arrow/util/bit_util.h
index 0d2b2655ea..1cbbf2042d 100644
--- a/cpp/src/arrow/util/bit_util.h
+++ b/cpp/src/arrow/util/bit_util.h
@@ -138,7 +138,14 @@ static inline uint64_t TrailingBits(uint64_t v, int num_bits) {
 // Returns ceil(log2(x)).
 static inline int Log2(uint64_t x) {
   // DCHECK_GT(x, 0);
+
+  // TODO: We can remove this condition once CRAN upgrades its macOS
+  // SDK from 11.3.
+#if defined(__clang__) && !defined(__cpp_lib_bitops)
+  return std::log2p1(x - 1);
+#else
   return std::bit_width(x - 1);
+#endif
 }
 
 //

[Anakin100100]

I think this is reasonable to deal with this issue now but this doesn't address the root cause which is relying on a 5 year old compiler. @jonkeane correct me if I'm wrong but cran builds their latest version for macOS 11.3 using Xcode 14.2 so even they don't attempt to build on 11.3 using the default one. Getting Xcode 14.2 would probably solve this issue while maintaining build compatibility with cran.

[jonkeane]

I think this is reasonable to deal with this issue now but this doesn't address the root cause which is relying on a 5 year old compiler. @jonkeane correct me if I'm wrong but cran builds their latest version for macOS 11.3 using Xcode 14.2 so even they don't attempt to build on 11.3 using the default one. Getting Xcode 14.2 would probably solve this issue while maintaining build compatibility with cran.

From a recent CRAN build, see which SDK version is being used:

used C++ compiler: ‘Apple clang version 14.0.3 (clang-1403.0.22.14.1)’
used SDK: ‘MacOSX11.3.1.sdk’

The test-r-macos-as-cran job has been specifically crafted to mimic this builder because we must be able to build on that until CRAN upgrades to something else. Us upgrading our CI will not change what CRAN is doing or help us stay on CRAN. There are more details in #49176 (and the PR that follows) as well as #49287 (and the PR that follows).

[jonkeane]

I just made the fixes for this in #49405