I am using coverity to analyze my code.
but when I configured cov, got an error.
> cov-configure --config
> /home/opt/coverity/Coverity/cov-admin/cov-conf/config/coverity_config_armcc.xml
> --comptype clang --compiler ****** --template
got an error:
Unknown compiler type clang
The only supported compiler types are:
******
So I'm doubt that if coverity supports clang compiler, or I have done something wrong.
The coverity version is 8.
BRs.
Coverity 8 definitely supports Clang. The issue is you're using --comptype clang - the comptype for Clang is --comptype clangcc (note the extra cc).
If you're in doubt, cov-configure --list-compiler-types is a good place to start, as is the documentation.
Note that so long as your Clang binary has the default name, cov-configure --clang should be all you need. Otherwise I strongly recommend you use --template on your cov-configure command line as well, as the CIT implementation for Clang makes heavy usage of "required" arguments and you're unlikely to get a successful capture of your build without using --template.
Related
http://llvm.org/docs/LibFuzzer.html
I'm doing some works with libfuzzer now but when I do with the official toy example. when i run this command:
clang++ -fsanitize=address -fsanitize-coverage=edge test-fuzzer.cc Fuzzer*.o
there is an error happening that
clang: error: invalid value 'edge' in 'fsanitize-coverage=edge'
it seems that clang supports this argument but i'm wondering how i can see what value is supported...
i installed llvm 3.6 by apt-get with unbuntu14.04...
The syntax of the fsanitize-coverage= flag has been changed, as described in this commit message from May 2015. This bit is particularly relevant to you:
Original semantics of -fsanitize-coverage flag is preserved:
* -fsanitize-coverage=0 disables the coverage
* -fsanitize-coverage=1 is a synonym for -fsanitize-coverage=func
* -fsanitize-coverage=2 is a synonym for -fsanitize-coverage=bb
* -fsanitize-coverage=3 is a synonym for -fsanitize-coverage=edge
* -fsanitize-coverage=4 is a synonym for -fsanitize-coverage=edge,indirect-calls
So you might try -fsanitize-coverage=3.
I'm not sure whether or not this question has a causality with my previous question.
So, I compiled Qt 5.3.1 from source with MinGW 4.8.2. The build stopped at qtbase/src/printsupport directory, as you can see the image below:
Is it a bug or something at qtbase/src/printsupport/kernel/qprintengine_win.cpp file? Then, should I just report it to the developer?
Look here it give you a hint. Probably somewhere you use this key -Werror in make files implicitly or explicitly when start compilation with gcc. If I correct understand error in that switch operation must be default: statement or case PPK_CustomBase: statement.
miraiE,
If you will notice in your output: cc1plus.exe: all warnings being treated as errors
This is, as was mentioned before, a warning that is stopping the compile process as an error.
You should be able to run you configure.bat script again, with the option -no-warnings-are-errors.
Then re-run your make.exe to get past this, and other warnings, from stopping the build.
Details of the specific configure options below:
../qtbase-opensource-src-5.3.1/configure --help |grep -i warn
-silent ............ Reduce the build output so that warnings and errors
-no-warnings-are-errors Make warnings be treated normally
-warnings-are-errors Make warnings be treated as errors
I hope this helps!
I'm running Clang 3.4 on Ubuntu 12.10 (from http://llvm.org/apt/). I ran the analyzer (clang --analyze) over some code, and it found a couple of issues:
Blah.C:429:9: warning: Declared variable-length array (VLA) has zero size
unsigned char separatedData[groupDataLength];
^~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~
But the specific issue isn't important. I want to know the steps of how it came to that conclusion (the code is complex enough for me not to see it within 15 mins).
I see a screenshot from the Clang site that shows steps of working viewed in a web browser:
That's probably obtained from Xcode.
The question is: how do I get Clang to output such steps of working from the command line? Or even output results to a browser if it so wishes? This would make the analyzer significantly more useful, and make fixing things much quicker.
(I have noticed that GCC's documentation is very excellent, but Clang/LLVM's documentation is very poor. I've tried "clang --analyze -Xanalyzer '-v'" as a stab in the dark to tell the analyzer to be more verbose -- the -Xanalyzer switch was from the man pages.)
In addition to text output on the console:
clang++ --analyze -Xanalyzer -analyzer-output=text main.cpp
You can get the full html output:
clang++ --analyze -Xanalyzer -analyzer-output=html -o html-dir main.cpp
Additionally, you can select specific checkers to enable. This page lists available checks. For example, you can enable all of the C++ checks in the alpha group using the flags:
-Xanalyzer -analyzer-checker=alpha.cplusplus
http://coliru.stacked-crooked.com/a/7746c4004704d4a7
main.cpp:5:1: warning: Potential leak of memory pointed to by 'x'
}
^
main.cpp:4:12: note: Memory is allocated
int *x = new int;
^~~~~~~
main.cpp:5:1: note: Potential leak of memory pointed to by 'x'
}
^
Apparently the front end exposes
-analyzer-config <Option Name>=<Value>
E.g.
-analyzer-config -analyzer-checker=alpha.cplusplus
which might be better supported than -Xanalyzer and may be getting extended to support options to individual checkers: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2014-October/039552.html
You are on the right track, but to get the full trace leading to a bug you additionally need to ask clang for output in text format (don't ask why). Since you will probably need to adjust e.g. include paths or defines for your project anyway I'd suggest you use clang-check which acts as a wrapper around clang's analyzer pass. It can also hook into the static analyzer tools exposed in e.g. scan-build. You can then
$ clang-check -analyze -extra-arg -Xclang -extra-arg -analyzer-output=text
Like you wrote the documentation for these very nice tools is abysmal. I cobbled above call together from bits and pieces from Chandler Carruth's GoingNative2013 talk.
You have to use scanbuild: http://clang-analyzer.llvm.org/scan-build.html
You type the commands that generate your build, but you pre-pend them with scan-build.
Example:
instead of
make
type
scan-build make
instead of
./configure
make
type
scan-build ./configure
scan-build make
Clear the build before launching the analyzer, otherwise make will state that everything has been built already and the analyzer will not run.
I'm trying to port buildsystem of my project to GNU autotools. The code need to be compiled with -std=c++11 or -std=c++0x flag. I want my configure script to check if compiler supports C++11 or not. I tried adding AX_CHECK_COMPILE_FLAG([-std=c++0x], [CXXFLAGS="$CXXFLAGS -std=c++0x"]) to configure.ac file but configure fails with this error:
...
./configure: line 2732: syntax error near unexpected token `-std=c++0x,'
./configure: line 2732: `AX_CHECK_COMPILE_FLAG(-std=c++0x, CXXFLAGS="$CXXFLAGS -std=c++0x")'
Hopefully there will be more comprehensive support for C++11 in future autoconf releases. In the mean time, I use a C++11 source test from ax_cxx_compile_stdcxx_11.m4 in the GNU autoconf archive:
AC_PROG_CXX
AC_LANG_PUSH([C++])
AC_COMPILE_IFELSE([AC_LANG_SOURCE(
[[template <typename T>
struct check
{
static_assert(sizeof(int) <= sizeof(T), "not big enough");
};
typedef check<check<bool>> right_angle_brackets;
int a;
decltype(a) b;
typedef check<int> check_type;
check_type c;
check_type&& cr = static_cast<check_type&&>(c);]])],,
AC_MSG_FAILURE(['$CXX $CXXFLAGS' does not accept ISO C++11]))
The error you're getting seems to come from AX_CHECK_COMPILE_FLAG not being expanded in your configure script. You can verify whether it is expanded by grepping AX_CHECK_COMPILE_FLAG in configure. If the grep finds it there, then it is not expanded.
You can also check it by looking into file aclocal.m4, where aclocal should copy it's definition.
The definition of this macro is not included in basic autoconf package, but in the autoconf archives. So you're probably missing this package. (Exact name of the package may differ between distributions, it is sys-devel/autoconf-archive in Gentoo and it seems to be autoconf-archive in Debian and Ubuntu).
When using gcc version 4.3.2, I see how to generate specs using:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
Now changing to the same directory as libgcc:
cd /usr/local/gcc-4.3.2/lib/gcc/x86_64-unknown-linux-gnu/4.3.2
/usr/local/gcc-4.3.2/bin/gcc -dumpspecs > specs
I have a populated specs file that I can modify. However, once that is done I still see that:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Using built-in specs
How do I tell gcc to use that specs file by default rather than forcing me to pass a -specs parameter every compile? I would like it to match another system I have where I get the following:
$ /usr/local/gcc-4.3.2/bin/gcc -v
Reading specs from /usr/local/gcc-4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/specs</code>
As you can see, the major difference between the two systems is that the existing setup is 32-bit and I am now trying to match that on a 64-bit system. The version of Linux is otherwise the same and I am compiling the same version of gcc. (With both systems gcc 4.3.2 is the second gcc installation, with 4.1.2 being used to compile 4.3.2)
As hinted at by the strace suggestion by Johannes Schaub - litb, it was a problem with where the compiler was looking for the file. As it turns out, the non-working installation had an environment variable set in the .bashrc that was causing the confusion.
The correct location for the specs file is indeed the same directory that libgcc is in. Just be sure you're looking there.
I used this command line:
/usr/bin/set-gcc-default-3.sh i686-pc-mingw32
but you'll probably want:
/usr/bin/set-gcc-default-4.sh i686-pc-linux-gnu
(Note the -4 instead of -3)
This is built using the "alternatives" stuff, please see
/usr/sbin/alternatives.exe --help
And also see pages such as http://linux.about.com/library/cmd/blcmdl8_alternatives.htm
You rebuild gcc with your specs file as part of the build!
A simpler solution is to create an alias:
alias gcc_Gary gcc -specs /<folder With Specs File>/newSpecsFile