I have a QNX specific code and I want to use clang-tidy for static analysis. Is this possible?
I am struggling because clang-tidy is supported by the clang compiler, and QCC (QNX compiler) is based on GCC.
Potentially yes. clang-tidy works with C++ source files and it mostly doesn't matter what compiler you use. As long as your program would compile with Clang, you can use clang-tidy.
However, although Clang is mostly compatible with GCC, the compatibility is not 100% proof and it may be confused if you use GCC / QCC specific features that are foreign to Clang. With standard, non-experimental C++ there should not be a problem.
Another consideration is that clang-tidy is typically used in conjunction with "compilation database", which invokes it with exact compiler options that you use to compile the program. Here again, Clang supports most GCC options either fully, or ignores them for compatibility, but some new, obscure or QCC specific options do cause an error.
Related
I have a c++14 project that currently targets gcc 7.2, and I am looking to backport code from a project that targets c++17. This project makes extensive use of if constexpr. gcc 7.2 supports if constexpr with the --std=c++1z flag, however it brings along all the other (at the time) experimental C++17 features.
Is there a way to enable only specific language features, in this case if constexpr, in gcc 7.2?
No it is not possible. It's all or nothing.
There is some limited level of control over language dialect in g++
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
If these dialects are used it can raise a warning and you can turn this warning into an error.
Another way could be to create plugins for clang-tidy or clang-query to check your C++ code base do not use any construct you don't want, but it becomes a rather large work to achieve the intended purpose.
There are cases that I want to know since which version of gcc a specific compiler flag or c++ language feature is supported so that I can write compile control preprocessors in source files or in CMakeLists.txt. For example, the compiler flag -wno-missing-field-initializers is not supported in gcc 3.4.3(an ancient version I have to use), but I want to know exactly since which version does gcc support that flag. Where can I find such instructions?
You can check specific flags using CheckCXXCompilerFlag
For example,
include(CheckCXXCompilerFlag)
CHECK_CXX_COMPILER_FLAG(-Wno-missing-field-initializers RESULT_OF_TEST)
Although a more portable option, across compilers, is to use CMAKE_CXX_KNOWN_FEATURES
See https://cmake.org/cmake/help/latest/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html
I am making a project using qmake and I want it to be easy to compile by many users. So far I was developing only for Linux and only for the gcc compiler. I would like my project to be compilable on other platforms too.
So far I passed the compiler options (which I found in the gcc documentation) to qmake like this:
QMAKE_CXXFLAGS += -std=c++14 \
-ffloat-store \
-O3 \
But then I realized that these options may not be valid on other compilers and tried to find equivalent options for other popular compilers, such as clang or Intel. To my surprise I found out that:
The optimization options -O0, -O1, -O2, -O3 are common to all three compilers.
The -std=c++11 and -std=c++14 options are common to gcc and clang
As far as I know, -ffloat-store and some other options are present only in gcc.
I wonder, is there some set of options, that is either formally or informally standard?
POSIX defines something about the c99 command (but AFAIK nothing about C++).
However, the qmake utility will usually be able to find out (or at least to expect) what is the C++ compiler and how to invoke it. Notice that it is generating a Makefile
Outside of Qt you might consider cmake or autoconf. They both generate Makefile-s.
See also this answer (on Programmers).
No.
The C++ standard doesn't cover any compiler option. This is something that can vary wildly between different implementations (or even different versions of the same implementation).
Off the top of my head, there's almost nothing in common between the major compilers.
The truth is, any non-trivial project requires some fine-tuning both in-code and the build process when you're aiming for multiple platforms. Your best bet is in my experience (and this is largely opinion-based), to craft the build process for each compiler to be as simple as possible, and fix most of the 'quirks' via pragmas in a platform/compiler specific include file that you "auto-include" everywhere.
I've looked hard for this question - it seems an obvious one to ask - but I haven't found it: Is a module compiled with "-std=c++11" (g++) binary compatible with modules that are not compiled with the option? (That is, can I link them together safely?) Both compilations would use the exact same version of g++.
To be more precise, using gcc 4.9.0, can I only use the "-std=c++11" on specific compilation units and then let the others compile without the option.
An authoritative reference can be found in gcc's C++11 ABI Compatibility page.
The short summary is: the are no language reasons the ABI gets broken but there are a number of mandated changes which cause the standard C++ library shipping with gcc to change.
What's the difference between llvmc.exe and clang.exe? Which one do I use for compiling C or C++ code?
llvmc is a frontend for various programs in the LLVM toolchain, in particular the llvm-* ones, ie by default it will try to use llvm-gcc and llvm-g++ to compile C and C++ files.
You can pass -clang to llvmc if that's what you want to use, and it's probably possible to configure llvmc so clang will be used by default, but I have no idea how to do that.
I'd recommend to just use clang and clang++ directly, which can be used as drop-in replacements for gcc and g++.
llvmc was an experimental driver that was intended to support multiple different source languages. Clang and Clang++ have always been the preferred way to drive the (C / C++ / Objective-C) compiler. In fact, llvmc has been removed from mainline.
In short, you should definitely use "clang" and never "llvmc".
LLVM originally stands for Low-Level Virtual Machine, and is today mostly used either:
as a backend optimizer/compiler
as a JIT compiler
On the other hand, Clang is a collection of libraries for dealing with the C language family that notably contains a compiler (clang) which acts as a front-end for C, C++, Objective-C and Objective-C++ on top of the LLVM libraries.
So, in your case, you will want to use clang and clang++ to compile C and C++ respectively, and don't worry about the fact that LLVM is used behind the scenes to optimize your code and deal with generation of machine instructions adapted to your architecture.