The title says it all. I looked everywhere on Clang's docs, but the option -gfull hasn't got any description.
The documentation also lacks information about all of the various debug levels (like -g2), and it would be cool if someone could explain that as well.
Apparently, options -g0, -g1, -g2, -g3 and -gfull in Clang are equivalent to GCC's. I could not find their documentation in Clang, but I found some info about their use in GCC (and they should behave the same in Clang, but I'm not 100% sure):
-gfull is used on Darwin/macOS. Using -gfull is equivalent to -g -fno-eliminate-unused-debug-symbols. Sources: link1 link2.
-g0 to -g3 are debug levels. They specify how much debugging information to include (note that -g0 means no debugging info at all). See here for a more detailed explanation (you find them under the paragraph -glevel).
EDIT:
All these command line options are listed in the Clang manual as GCC-compatible options (source). Therefore, the behavior described in the GCC manual should be the same in Clang.
P.S.: I've already said that in the original answer, but now I added a link to the Clang manual as source.
Related
The title is quite clear, is there a way to disable every single non-standard feature of gcc (extension) when compiling some C++ code. I've previously always used -pedantic-errors alongside -Wall and -Wextra, the first according to the gcc man page does the following
Give an error whenever the base standard (see -Wpedantic) requires a diagnostic, in some
equivalent to -Werror=pedantic, since there are errors enabled by this option and not
particular library's limitations. However, if -Wpedantic is used with -Wformat, warnings
made into an error by -pedantic-errors.
-Wall or -Wpedantic.
As a result it disables practically all extensions that aren't standard conforming, however. I was rather shooked that the following code compiles with gcc
void foo(std::vector<auto>) { ... }
with the -std=c++20 flag, if we bump it down to -std=c++17 we receive an error message prompting the use of -std=c++20 as it's a "c++20 feature". However neither clang or msvc is willing to compile this. After some further research I was notified of the following
This is a GCC extension and accepted by design.
Which is rather upsetting as even the safe-guards of -pedantic-errors, -Wall and -Wextra didn't pick this up, which leads me to question what other extensions might be silently passed through by gcc. Thus the question comes; is there any way to disable exactly every gcc extension?
Edit: From the comment section of How to disable GNU C extensions?
You cannot
I have an issue when building my C++ project that uses boost in Emscripten as shown on the screenshot, it says that '_Atomic' is a C11 extension however even if i add -std=c++11 or even -std=c11 i am still getting the error, the _Atomic use is defined from boost.
any idea on how to work around on this? reading around it does say that C++11 is already supported in Emscripten.
my setup.
compiler: emscripten/em++ Clang 12.0.8
Why
The message in your screenshot shows:
you are compiling with clang
error: '_Atomic' is a C11 extension [-Werror,-Wc11-extensions]
So clang warns on c11 extensions because it has the diagnostic flag set, and is also configured to fail on warning which leads to your failed compilation.
-Wc11-extensions may have been specified directly in your compilation commands
or indirectly by -Wpedantic (see https://clang.llvm.org/docs/DiagnosticsReference.html#id604)
How to fix
You could specifically deactivate this warning with the -Wno-c11-extensions compiler flag, see this good explanation here on how to do it: https://nelkinda.com/blog/suppress-warnings-in-gcc-and-clang/
I'm reading this tutorial about code vectorization using Intel Advisor. In particular in this page they suggest to:
Build the target sample application in release mode ... compiler options: -O2 -g
And following:
To build your own applications to produce the most accurate and
complete Vectorization Advisor analysis results, build an optimized
binary in release mode using the following settings.
-g -O2 (or higher) -qopt-report=5 -vec -simd -qopenmp
Now, I have a couple of questions:
I thought that in release mode we didn't produce any debug information (which is produced in the "debug mode"), so no -g should be included
The weirdest thing is that in the Makefile given for the samples code (vec_samples in /opt/intel/advisor_*/...) uses only -g -O2 why they don't include all the other options. Why?
The relevant entry point to fresh Intel Advisor tutorials is Getting Started, where you can pick and choose appropriate sub-tutorials. Vectorization Advisor sub-tutorial for Linux can be found here. It precisely says that:
-qopt-report=5 : necessary for version 15.0 of the Intel compiler; unnecessary for version 16.0 and higher
With regards to -vec, -simd, -openmp, the tutorial slightly confuses flags needed for proper Advisor functioning (-g, -O2, optionally -opt-report) vs. flags needed for "proper" Compiler functioning ( -vec, -simd and -openmp). The later ones are just flags controlling compiler's vector code generation, they have nothing to do with Advisor profiling capabilities so you may or may not use them.
To give you deeper understanding: there is an important feature in
Advisor, which is called Intel Advisor Survey "Compiler Integration".
This feature leverages the data relatively similar but not identical to opt-report.
In order to make this feature working you need
Using Intel Coimpiler 14.x beta, 15.x, 16.x or 17.x
-g (enable debug info) and -O2 or higher (enable some optimization)
Optional (for Intel Compiler 15.x only) -qopt-report5
All other features in Intel Advisor work equally well regardless of Compiler version (item 1 above) or opt-report and versions (item 3 above) , but they all still require -g (part of option 2 above). -O2 is not needed for some features, but it is typically useless to deal with -O0 or -O1 compiled binaries when analyzing performance aspects.
With gcc and clang, I routinely use -Wall -Wextra warning flags.
What command line switches for Visual C++ 2010 (and newer, if there are differences) would produce about same result?
This MSDN document page provides the technical details, but I am after a more qualitative answer from Visual C++ developers, based on practical experience: A "rule of thumb" flags you can safely throw on any new project when you start, that would still catch approximately the same things that -Wall -Wextra of the other compilers catch.
I agree with #Paulius's answer here which you linked to in the comments. /W4 will show you all warnings that are not disabled by default, which is probably the closest you can get to "approximately the same things" without searching through each of the warnings individually and enabling the equivalent. /Wall in MSVC will do what it says and turn on all warnings (even the questionable ones), which for any non-trivial project will give false positives. This is different from gcc -Wall, which will only turn on warnings that are not "questionable".
Well... When i was searching for a good compiler I came across clang/LLVM. This compiler gives me same result as other compilers like icc, pgi. But the problem is there are very few tutorials on this compiler... Kindly let me know where can I find the tutorials on the clang compiler.
Note by:
I have compiled my c code using the following flags clang -O3 -mfpmath=sse file.c
Clang (the command line compiler) takes gcc-compatible options, but accepts and ignores a lot of flags that GCC takes (like -mfpmath=sse). We aim to generate good code out of the box. There are some flags that allow clang to violate the language standards that can be useful in some scenarios, like -ffast-math though.
If you're looking for good performance, I highly recommend experimenting with link-time-optimization, which allows clang to optimize across source files in your application. Depending on what platform you're on, this is enabled by passing -O4 to the compiler. If you're on linux, you need to use the "gold" linker (see http://llvm.org/docs/GoldPlugin.html). If you're on the mac, it should "just work" with any recent version of Xcode.
The clang is not a compiler, it is just frontend of LLVM compiler. So, when you calls clang, it parses c/c++ file but the optimization and code generation is handled in LLVM itself.
Here you can found a documentation of LLVM optimization and analysis options: http://llvm.org/docs/Passes.html
The full documentation is here http://llvm.org/docs/
Also useful options are listed here http://linux.die.net/man/1/llvmc (I suggest clang will accept most of them too)