Fails to build with clang/LLVM

[candrews]

cpuminer-opt fails to compile with LLVM. Here's full build output: https://731678.bugs.gentoo.org/attachment.cgi?id=648302

There are a few errors... here's one of them:

In file included from util.c:27:
./sysinfos.c:1:2: warning: 'SYSINJFOS_C___' is used as a header guard here,
      followed by #define of a different macro [-Wheader-guard]
#if !defined(SYSINJFOS_C___)
 ^~
./sysinfos.cIn file included from cpu-miner.c:40:
./sysinfos.c:1:2: warning: 'SYSINJFOS_C___' is used as a header guard here,
      followed by #define of a different macro [-Wheader-guard]
#if !defined(SYSINJFOS_C___)
 ^~
./sysinfos.c:2:9: note: 'SYSINFOS_C__' is defined here; did you mean
      'SYSINJFOS_C___'?
#define SYSINFOS_C__
        ^~~~~~~~~~~~
        SYSINJFOS_C___
:2:9: note: 'SYSINFOS_C__' is defined here; did you mean
      'SYSINJFOS_C___'?
#define SYSINFOS_C__
        ^~~~~~~~~~~~
        SYSINJFOS_C___

This issue was originally reported downstream at https://bugs.gentoo.org/731678

[JayDDee]

I know nothing of LLVM so this will be difficult. But I expect LLVM should be transparent. However, there are a lot more warnings, and one error (repeated) when using LLVM. I'll try to characterize some of them.

Is there any history that could provide some context? Is this the first attempt to use LLVM?

In file included from util.c:27: ./sysinfos.c:1:2: warning: 'SYSINJFOS_C___' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]

if !defined(SYSINJFOS_C___)

this is a legitimate bug due to a typo in sysinfos.c. The effect is the possibility of muitiple inclusions of the header code. This warning may not be LLVM related but a new GCC warning. This could also point to a possible GCC version incompatibility.

Edit: although a typo broke the header guard it wasn't needed as there were no instances of multiple inclusions. This warning seems to be a trivial issue unrelated to the compile failure.

2.

./simd-utils/simd-int.h:48:9: warning: 'bswap_32' macro redefined [-Wmacro-redefined] Thius

define bswap_32( a ) __builtin_bswap32( a )

This is likeky a multiple inclusion bug that I'll have to track down. "-Wheader-guard" isn't available in GCC 9 so it will be difficult.

Edit: I can't find a reason for the multiple definition of bswap_32, it's protected by a header guard. It's also worth noting its companion bswap_64 does not produce this warning. That suggests bswap_32 is being defined outside cpuminer-opt.

3.

In file included from ./simd-utils.h:146: ./simd-utils/simd-int.h:88:4: warning: "__int128 not supported, requires GCC-4.8 or newer." [-W#warnings]

warning "__int128 not supported, requires GCC-4.8 or newer."

int128 is tested as supported by configure but the fails in the code. The test in the code is based on the GCC version using the GNUC and GNUC_MINOR__ macros, suggesting the macros were not defined.

4.

In file included from algo/argon2/argon2a/ar2/sj/scrypt-jane-portable.h:306: algo/argon2/argon2a/ar2/sj/scrypt-jane-portable-x86.h:313:3: error: unknown token in expression a2(mov [%1 + 0], eax) ^

This is the only error (reported) preventing compilation. It is in ASM code that was imported from another program so I'm not familiar with it. Of note is the code uses preprocessor macros.

Preprocessor macros seems to be a common theme in all 4 cases. Maybe there is an incompatible change in a new version of GCC. Some more testing is required to determine whether LLVM works with GCC 9 and whether your version of GCC works without LLVM.

It would be prefereable to test with the latest version of cpuminer-opt.

[JayDDee]

This problem could be related to the CPU, it appears to be a virtualized AMD EPYC. Try compiling with LLVM for a specific architecture instead of native.

[JayDDee]

I took a look at the Gentoo bug and it mentions using Clang. That would explain the __int128 warning as it checks for GCC.

AFAIK Clang doesn't work with cpuminer-opt. Apparently it doesn't seem to like some of the ASM. You can confirn this by compiling with GCC/LLVM or Clang without LLVM.

[JayDDee]

Now I'm confused. Is it GCC or Clang?

The log file clearly states GNUC was configured and the compiler output looks exactly like GCC but the Gentoo bug report says Clang was used.

Can someone clarify?

[JayDDee]

There doesn't seem to be much interest in this issue. That's fine with me because I have no interest in trying to support Clang or LLVM.

Clang has never been supported and trying to do so would be a lot of work with high risk and no apparent benefit.

LLVM should be transparent. Any source code that compiles with pure GCC should also compile with GCC/LLVM.