Cross-GCC and C11 atomics incompatibility (with workaround)

[yalfg]

Describe the bug When using CodeChecker on source using C11 atomics and compiled with a GCC cross compiler, clang tools fails (CTU parsing, tidy, sa).

CodeChecker version Using version 6.18.0.

To Reproduce Using a dummy atomic_test.c file:

#include <stdatomic.h>

static atomic_int counter;

int
my_inc(void)
{
    return atomic_fetch_add(&counter, 1);
}

Compile and build a compilation database with a GCC cross compiler. I used ARM Aarch64 bare metal GCC 9.2:

bear -- aarch64-none-elf-9.2-2019.12-gcc -O2 -Wall -c -o atomic_test.o atomic_test.c

Then run CodeChecker on the resulting compilation DB:

CodeChecker analyze -o pfiles  compile_commands.json

The analysis will fails, with a complaint that the call uses an invalid, non atomic argument (not the case):

[ERROR 2021-11-21 18:57] - 
/home/user/atomic-bug/atomic_test.c:8:12: error: address argument to atomic operation must be a pointer to integer or pointer ('atomic_int *' (aka '_Atomic(int) *') invalid)
    return atomic_fetch_add(&counter, 1);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/cross-tools/gcc-arm-9.2-2019.12-x86_64-aarch64-none-elf/lib/gcc/aarch64-none-elf/9.2.1/include/stdatomic.h:192:36: note: expanded from macro 'atomic_fetch_add'
#define atomic_fetch_add(PTR, VAL) __atomic_fetch_add ((PTR), (VAL),    \
                                   ^                   ~~~~~
1 error generated.

[ERROR 2021-11-21 18:57] - Analyzing atomic_test.c with clang-tidy  failed!

Expected behaviour The analysis should be successful, as the code is valid C11.

Desktop (please complete the following information)

• OS: Linux Debian Bullseye
• Cross GCC 9.2

The OS version shouldn't be relevant. The cross GCC version shouldn't either (related bug reports indicate it's an old issue), but TBC. I've only checked with this ARM GCC 9.2 version.

Additional context GCC internal stdatomic.h header file is not compatible with Clang, this is a know issue it seems. The issue here is that with a cross GCC CodeChecker will extract the GCC internal include paths and use them, leading Clang tools to pick GCC internal version of stdatomic.h. This is what causes the failure.

To workaround this, we need to special case stdatomic.h. The following works:

1. Add to the compiler_info.json generated by CodeChecker a fake compiler include directory, in first position;
2. In this fake directory, but a minimal stdatomic.h file that will force a redirection to the host Clang version. The following works (please adjust based on Clang version and installation location):

#pragma once
#undef __STDC_HOSTED__
#define __STDC_HOSTED__ 0
#include "/usr/lib/llvm-11/lib/clang/11.0.1/include/stdatomic.h"

3. Use CodeChecker with the '--compiler-info-file' option to pick the modified compiler info.

With the above, Clang tools will use the GCC cross headers, except for stdatomic.h. And the analysis of files using C11 atomics will work fine.

Could this process be automated by CodeChecker please?

Thanks