Why clang documentation doesn't contain information on a lot of options? - clang

At work, I work on a C++ program which uses Cmake. In the top-level CMakeLists.txt, the CMAKE_CXX_FLAGS_DEBUG flag is set for Clang to input the different flags we want for the compilation.
My problem is that I see previous developers on the project put a lot of compilation options I don't understand for clang and I don't find them in the documentation... I don't understand why they aren't documented ! Moreover, I really wonder how the previous developers had the idea to put them in the code if they couldn't find them in the official documentation !
Here is a few examples of flags I couldn't find in the documentation :
-Wno-covered-switch-default
-Wno-exit-time-destructors
-Wno-padded
-Wweak-vtables

Related

How can I find the flag dependency or conflict in LLVM?

As I know, GCC has this website to figure out the relationship between different flags using while optimization. GCC example website. Like fpartialInlining can only be useful when findirectInlining is turned on.
I think the same thing would happen in clang, in other words, I think the different passes may have this kind of dependcy/confilcts relationship in LLVM(CLANG).
But after checking all the document provided by developers, I find it just say something about the functionality in these passes. LLVM PASS DOC
So my question can be divided into 2 parts I think:
Does the dependency exists in LLVM PASS or there is no such dependency/conflicts
If there is, how can I find them.
You can find which passes are using in which optimization levels by clang while compiling any c or c++ code with clang and try to figure out dependencies. For example:
clang -O2 --target=riscv32 -mllvm -debug-pass=Structure example.c
(You can use also -debug-pass=Arguments instead of -debug-pass=Structure. It depends readability.)
this will give which passes used by clang at 2. optimization level for riscv32 target. If you don't give a target it sets default as your host machine target, and keep in mind that some used passes changes related to different targets at same optimization levels.

Full Clang warning list with descriptions

I need to get full Clang warnings list. With Descriptions. For iOS.
I've seen just a list of warnings here
Clang Warnings
But there is no description.
Is there any place where i can get full list of Clang warnings with the description?
I realize this is an old question, but a complete list of warnings, along with the text printed for each one, can be found in the Clang Documentation.
(Note: This answer is now outdated.)
There's a neat project that shows the flags alongside their warning messages:
https://github.com/NSHipster/fuckingclangwarnings.com
While these are not comprehensive explanations in all cases, it is very helpful, especially when you want to switch off specific warnings.
The project hasn't been updated in a while and is probably missing a few new warnings. You could also dive into Clang's source code. I haven't worked with it in a while, but I can tell you where to start:
Clone the Clang repository
Browse to /include/clang/Basic/Diagnostic.td. This file includes a couple of other .td files which contain the various warnings, though I'm not sure if all of them are publicly available, and I think their external names are prefixed, depending on their category. I suggest searching for a known warning (or its description) to solve the puzzle.
Another interesting file is /include/clang/Driver/Options.td, which includes the texts you get using the help command, if I recall correctly.
The [current] accepted answer is correct. clang/clang++'s documentation up on the website doesn't necessarily reflect the supported options in the code. As the old phrase goes, "the source code is the documentation" :/..
One thing that will help with finding options is grepping the source code for DiagGroup. For example, the following demonstrates an attempt at grepping for sign-compare, aka -Wsign-compare, using a pared down clang 7.0.1 source checkout:
$ grep --include \*.td -r sign-compare . | grep DiagGroup
tools/clang/include/clang/Basic/DiagnosticGroups.td:def SignCompare : DiagGroup<"sign-compare">;

LLVM compilation process and LLD

I've been trying to make the switch to LLVM, since I'd like to get more into the whole 'software-dev' scene, and it seems like right now, LLVM is the future. I built LLVM/Clang/LLD/compiler-rt/libcxx from source several times now, both with GNU/GCC and LLVM/Clang.
The problem appears when I try to use the newly compiled compilers. From what I can see, clang is using GNU ld rather than LLVM's lld. Is this true?
LLD seems to be a very limited program from the lld -help output, but from what I have read, it is as full featured as ld. I cannot find documentation on how to use it anywhere -- does anyone know where I can find some kind of comprehensive manual on it?
Thank you.
Pass -fuse-ld=lld to clang to make it use lld for linking. By now, it's in very good shape.
You can pass -v or -### to clang to make it print which linker command it runs or would run.
There's no manual for the moment and depending on platform may work well enough for you. That said, if lld were "production ready" we'd have switched clang to using it by default for the various platforms. It's not there yet so I wouldn't suggest you use it for your day to day development.
The LLVM team say that is production ready because FreeBSD can compile and link a lot of things with LLD.
The documentation on the LLD project can be found on http://lld.llvm.org/.
It's written :
LLD is a drop-in replacement for the GNU linkers.
That accepts the same command line arguments and linker scripts as GNU.
So you can use same arguments than GNU LD.
I know this question is old, but there is a newer solution to it:
To use the ld.lld linker when building any llvm target, just pass -DLLVM_ENABLE_LLD=ON in the commandline to cmake.
//Use lld as C and C++ linker.
LLVM_ENABLE_LLD:BOOL=TRUE
For other cmake projects, pass: -DCMAKE_LINKER=/etc/bin/ld.lld

Is there an easy way to use clang with Open MPI?

OpenMPI strongly recommends using their wrapper compilers. Behind the scenes, their wrapper compiler mpiCC calls gcc (by default?) and adds the necessary flags for MPI code to compile. However, other compilers give more descriptive error messages than gcc (e.g. clang which is also GCC-compatible). So, I'd like to be able to use clang with Open MPI.
I tried:
1) finding an mpiCC option for specifying the compiler, but
mpiCC --help
just spits out the g++ help page.
2) using the --showme:compile option
mpiCC --showme:compile ./test-boost.cc -lboost_mpi -lboost_serialization -o test-boost
which, instead of calling gcc, prints the flags needed for compiling the MPI code. I can then use those with clang (since it's GCC-compatible). This should work, but I'm looking for an easier solution.
Open MPI FAQ says which environmental variables can be set to override the default choice of the compiler called by the wrapper.
http://www.open-mpi.org/faq/?category=mpi-apps#override-wrappers-after-v1.0
Depending on the version of OpenMPI you should set OMPI_CXX=clang++ or OMPI_MPICC=clang. For OpenMPI v.1.1 and later use OMPI_CXX and then call the wrapper compiler. The wrapper would call clang++ in turn.
Setting OMPI_CC=clang or OMPI_CXX=clang++ as environment variables in .bashrc, as described in the official FAQ of OpenMPI, is NOT working for me. I have to attach them ahead whenever I use mpicc, e.g.
OMPI_CC=clang mpicc --showme:command
So in Makefile, I set CC=OMPI_CC=clang mpicc, which works well for me.

Localizing clang output

Are the clang C compiler's diagnostic messages (warning, errors, etc.) hard-coded, or does it provide a way to specify which language (as opposed to English) to emit them in? Could I provide a custom dictionary for it to use at runtime, without building my own clang from source?
Clang's diagnostics are currently hard-coded, but the system is designed to support localization. You can read some information about how it works here:
http://clang.llvm.org/docs/InternalsManual.html#Diagnostics
We'd really like help localizing. If this is an area that you're interested in helping out, please contact the cfe-dev mailing list!

Resources