test_stack fail on E2K in 64-bit mode

[ivmai]

Source: master (30db756)
Host: Linux ... 5.4.0-6.9-e8c #1 SMP ... e2k E8C E8C-SWTX GNU/Linux
Compiler: lcc:1.26.20:Jun--6-2023:e2k-v4-linux (gcc (GCC) 9.3.0 compatible)
How to reproduce: ./autogen.sh && ./configure && make check CFLAGS_EXTRA="-m64 -D AO_PREFER_BUILTIN_ATOMICS" LDFLAGS="-latomic"
Output (tests/test_stack.log):
Failed - nothing to pop

[ilyakurdyukov]

На v4 нет 128-bit атомарных операций, для v5 и далее - есть, так в МЦСТ ответили и баг закрыли. Версию архитектуры можно узнать на этапе компиляции по значению макроса __iset__.

[ivmai]

Tip for me: code of libatomic - https://github.com/OpenE2K/gcc/tree/gcc-runtime-mcst/libatomic

[ivmai]

На v4 нет 128-bit атомарных операций, для v5 и далее - есть, так в МЦСТ ответили и баг закрыли. Версию архитектуры можно узнать на этапе компиляции по значению макроса __iset__.

Got it. Thank you! I will do a compile-time check based on the macro.

[ivmai]

Note: there was also a suggestion to use a runtime check (`__builtin_cpu_arch()') but according to the design of libatomic_ops availability of a particular atomic operation should be detectable thru a macro.

[ilyakurdyukov]

И еще добавили, что в v4 есть атомарные 128-бит запись/чтение, это для указателей 128-бит режима. Но нет эквивалента exchange/compare_exchange на 128 бит.

[ivmai]

И еще добавили, что в v4 есть атомарные 128-бит запись/чтение, это для указателей 128-бит режима. Но нет эквивалента exchange/compare_exchange на 128 бит.

О, спасибо, это понадобится когда буду добавлять поддержку ЗР в libgc.

[ilyakurdyukov]

Предлагают вместо __iset__ использовать проверку на макрос __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 для определения наличия интринсика в компиляторе, для Clang тоже работает.

[ivmai]

Предлагают вместо __iset__ использовать проверку на макрос __GCC_HAVE_SYNC_COMPARE_AND_SWAP_16 для определения наличия интринсика в компиляторе, для Clang тоже работает.

I agree that about gcc your suggestion is good, but not for clang: clang -m64 -dM -E ... | grep GCC_HAVE_SYNC gives nothing.
But I will use it at least for gcc. Thank you!

[ilyakurdyukov]

Для Clang-9 на x86_64 это работает (https://godbolt.org/z/P7Gqoa3qM):

#ifndef __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8
#error
#endif

На 16 байт у x86_64 нет.

В Clang от МЦСТ интринсики вроде есть, а макроса нет. На это баг уже завели.

Но это был совет от МЦСТ с этим макросом, я бы предпочёл использовать __iset__, чем непонятные макросы от компилятора.

[ivmai]

Для Clang-9 на x86_64 это работает (https://godbolt.org/z/P7Gqoa3qM):
На 16 байт у x86_64 нет.

Да, интринсик есть для 16 байт а макроса нет. У Clang.

[ivmai]

В Clang от МЦСТ интринсики вроде есть, а макроса нет. На это баг уже завели.

There 2 extra issues with clang 16-byte compare and exchange (I mean difference from gcc) besides absence of the feature macro:

src/atomic_ops/sysdeps/gcc/generic.h:227:19: warning: large atomic operation may incur significant performance penalty; the access size (16 bytes) exceeds the max lock-free size (8  bytes) [-Watomic-alignment]
      return (int)__atomic_compare_exchange_n(&addr->AO_whole,
                  ^
1 warning generated.
/usr/bin/ld: /tmp/atomic_ops_stack-eb3351.o: в функции «AO_stack_pop_acquire»:
-:(.text+0x26c): неопределённая ссылка на «__atomic_compare_exchange»
/usr/bin/ld: -:(.text+0x36c): неопределённая ссылка на «__atomic_compare_exchange»
clang-13: error: linker command failed with exit code 1 (use -v to see invocation)

As a workaround this could be used by client: CFLAGS=-Wno-atomic-alignment LDFLAGS=-latomic