Build is broken due to this error: no member named 'load' in 'deque_anchor<T>'

[yurivict]

Actual Behavior

In file included from /wrkdirs/usr/ports/devel/pika/work/pika-0.29.0/libs/pika/schedulers/include/pika/schedulers/lockfree_queue_backends.hpp:15:
/wrkdirs/usr/ports/devel/pika/work/pika-0.29.0/libs/pika/concurrency/include/pika/concurrency/deque.hpp:149:59: error: no member named 'load' in 'deque_anchor<T>'
  149 |             return pair_.compare_exchange_strong(expected.load(std::memory_order_acquire),
      |                                                  ~~~~~~~~ ^
/wrkdirs/usr/ports/devel/pika/work/pika-0.29.0/libs/pika/concurrency/include/pika/concurrency/deque.hpp:150:25: error: no member named 'load' in 'deque_anchor<T>'
  150 |                 desired.load(std::memory_order_acquire), mo);
      |                 ~~~~~~~ ^
/wrkdirs/usr/ports/devel/pika/work/pika-0.29.0/libs/pika/concurrency/include/pika/concurrency/deque.hpp:157:35: error: no member named 'load' in 'deque_anchor<T>'
  157 |                 expected, desired.load(std::memory_order_acquire), mo);
      |                           ~~~~~~~ ^
/wrkdirs/usr/ports/devel/pika/work/pika-0.29.0/libs/pika/concurrency/include/pika/concurrency/deque.hpp:164:26: error: no member named 'load' in 'deque_anchor<T>'
  164 |                 expected.load(std::memory_order_acquire), desired, mo);
      |                 ~~~~~~~~ ^
4 errors generated.

log

The error appeared after llvm/clang was updated in the FreeBSD base.

There is really no method 'load' in the class in question, so it's amazing that this class is even compiled by any C++ compiler.

Specifications

... Please describe your environment

• pika version (commit/tag): 0.29.0
• Platform (OS, compiler, etc.): FreeBSD 14.1

[msimberg]

Thanks for the report. I've also seen this on #1283, but don't understand what's triggering the problem yet. It doesn't quite make sense to me that the code even compiles in the first place. In any case, I'm trying to get #1283 done relatively soon, which will require fixing/working around that error.

[msimberg]

@yurivict I've added some references to the PR description of #1283 in case you want to have a look. It does seem like an intentional change in clang 19 (and GCC 15 will probably follow). But it's obviously a bug on our side and #1283 fixes it (by removing the offending functions since they were unused).

[yurivict]

Thanks!