How to suppress a warning in clang++? - warnings

I compiled the following c++ program:
int main() { 2==3; }
with:
clang++-5.0 -std=c++17 -Wunused-comparison prog.cpp
and got the warning:
warning: equality comparison result unused [-Wunused-comparison]
2==3;
~^~~
... so, probably this is not the correct way to suppress a warning in CLANG.
In the clang manual, this part is a "TODO".
What is the correct command-line flag to disable a warning?

In the clang diagnostic that you get from:
$ cat main.cpp
int main()
{
2==3;
return 0;
}
$ clang++ -c main.cpp
main.cpp:3:6: warning: equality comparison result unused [-Wunused-comparison]
2==3;
~^~~
1 warning generated.
the bracketed:
-Wunused-comparison
tells you that -Wunused-comparison is the enabled warning (in this case enabled by default) that was responsible for the diagnostic. So to suppress the diagnostic you explicitly disable that warning with the matching -Wno-... flag:
$ clang++ -c -Wno-unused-comparison main.cpp; echo Done
Done
The same applies for GCC.
In general, it is reckless to suppress warnings. One should rather enable them generously - -Wall -Wextra [-pedantic] - and then fix offending code.

add no warning flag as : -Wno-xxx :
https://releases.llvm.org/12.0.0/tools/clang/docs/DiagnosticsReference.html#diagnostic-flags
e.g.
enable the c++17 extension warning:
-Wc++17-extensions
suppress the c++17 extension warning:
-Wno-c++17-extensions

Related

CUDA + CMake target library dependence breaks on different machine

I recently tried to build my https://github.com/eyalroz/cuda-api-wrappers/ library's examples after switching to another Linux distribution on the same machine. Strangely enough, I encountered a linking issue. The command:
/usr/bin/c++ -Wall -std=c++11 -g CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o -o examples/bin/device_management -rdynamic lib/libcuda-api-wrappers.a -Wl,-Bstatic -lcudart_static -Wl,-Bdynamic -lpthread -ldl -lrt
fails to find the CUDA runtime library, and I get:
CMakeFiles/device_management.dir/examples/by_runtime_api_module/device_management.cpp.o: In function `cuda::device::peer_to_peer::get_attribute(cudaDeviceP2PAttr, int, int)':
/home/eyalroz/src/mine/cuda-api-wrappers/src/cuda/api/device.hpp:38: undefined reference to `cudaDeviceGetP2PAttribute'
collect2: error: ld returned 1 exit status
but if I add -L/usr/local/cuda/lib64 it builds fine. This didn't use to happen before; and it doesn't happen on another machine I've checked on, nor does it even happen to other targets using the CUDA runtime in the same CMakeLists.txt (like version_managament).
FindCUDA seems to be finding everything, as the value of ${CUDA_LIBRARIES} is /usr/local/cuda/lib64/libcudart_static.a;-lpthread;dl;/usr/lib/x86_64-linux-gnu/librt.so. And the target lines in CMakeLists.txt are:
add_executable(device_management EXCLUDE_FROM_ALL examples/by_runtime_api_module/device_management.cpp)
target_link_libraries(device_management cuda-api-wrappers ${CUDA_LIBRARIES})
as is suggested in answers to other related questions (e.g. here). Why is this happening? Should I "manually" add the -L switch?
Edit: Following #RobertCrovella's suggestion, here are the ld search paths:
$ gcc -print-search-dirs | sed '/^lib/b 1;d;:1;s,/[^/.][^/]*/\.\./,/,;t 1;s,:[^=]*=,:;,;s,;,; ,g' | tr \; \\012 | tr ':' "\n" | tail -n +3
/usr/local/cuda/lib64/x86_64-linux-gnu/5/
/usr/local/cuda/lib64/x86_64-linux-gnu/
/usr/local/cuda/lib/
/usr/lib/gcc/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/5/
/usr/x86_64-linux-gnu/lib/x86_64-linux-gnu/
/usr/x86_64-linux-gnu/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/lib/x86_64-linux-gnu/5/
/lib/x86_64-linux-gnu/
/lib/
/usr/lib/x86_64-linux-gnu/5/
/usr/lib/x86_64-linux-gnu/
/usr/lib/
/usr/local/cuda/lib64/
/usr/x86_64-linux-gnu/lib/
/usr/lib/
/lib/
/usr/lib/
$ ld --verbose | grep SEARCH_DIR | tr -s ' ;' \\012
SEARCH_DIR("=/usr/local/lib/x86_64-linux-gnu")
SEARCH_DIR("=/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/lib/x86_64-linux-gnu")
SEARCH_DIR("=/usr/local/lib64")
SEARCH_DIR("=/lib64")
SEARCH_DIR("=/usr/lib64")
SEARCH_DIR("=/usr/local/lib")
SEARCH_DIR("=/lib")
SEARCH_DIR("=/usr/lib")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib64")
SEARCH_DIR("=/usr/x86_64-linux-gnu/lib")
Notes:
Yes, I know the CMakeLists.txt there is ugly.
TL;DR:
After the FindCUDA invocation, add the lines:
get_filename_component(CUDA_LIBRARY_DIR ${CUDA_CUDART_LIBRARY} DIRECTORY)
set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} "-L${CUDA_LIBRARY_DIR}")
and building should succeed on both systems.
Discussion:
(Paraphrasing #RobertCrovella and myself in the comments:)
OP was expecting, that if the following hold:
FindCUDA succeeds
${CUDA_LIBRARIES} includes a valid full path to either the static or the dynamic CUDA runtime library
the library dependency is indicated using target_link_libraries(relevant_target ${CUDA_LIBRARIES})
... then the CMake-based build he was attempting should succeed on a variety of valid CUDA installations. That is (unfortunately) not the case, since while FindCUDA does locate the CUDA library path, it does not actually make your linker search that path. So a failure should actually be expected. The build had worked on OP's old system due to a "fluke", or rather, due to OP having added the CUDA library directory to the linker's search path, somehow, apriori.
The linking command must be issued with the -L/path/to/cuda/libraries switch, so that the linker knows where to looks for the (unspecified-path) libraries referred to be the CUDA-related -l switches (in OP's case, -lcudart_static).
This answer discusses how to do that in CMake for different kinds of targets. You might also want to have a look at man gcc (the GCC manual page, also available here) regarding the -l and -L options, if you are not familiar with them.

Caffe compilation fails: Undefined symbols for architecture x86_64?

If I try building the newest version of Caffe, it leads to this error:
$ make all
CXX/LD -o .build_release/tools/caffe.bin
clang: warning: argument unused during compilation: '-pthread'
Undefined symbols for architecture x86_64:
"caffe::Net<float>::Forward(float*)", referenced from:
test() in caffe.o
time() in caffe.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [.build_release/tools/caffe.bin] Error 1
I'm building on osx, OpenBLAS, and CPU_ONLY. I found a kind of similar issue on here but it appears to have been a resolved issue, and I'm not getting the exact same error, though perhaps it's related? I can also build and run an older version of Caffe from a month ago, so I think something has changed very recently.
Any ideas on how to overcome this error?
It shows a link problem when compile.On osx this problem will happen usually.I guess the problem happened in Makefile.config.You can change to
# To customize your choice of compiler, uncomment and set the following.
# N.B. the default for Linux is g++ and the default for OSX is clang++
CUSTOM_CXX := g++
and confirm some path is correct.
I had exactly the same problem. Its now resolved.
Do check if you already have a libcaffe.so in your system library paths (maybe /usr/local/lib). If so, delete the existing libcaffe.so and build again.

zlib, harsh compiler warnings and configure test

I'm trying to compile zlib from the command line, and I'm getting this message when using -Wall -Wextra -Wconversion (full cross-compile script is below):
Compiler error reporting is too harsh for ./configure (perhaps remove
-Werror).
Here's the configure test that's generating the line:
cat > $test.c << EOF
int foo() { return 0; }
EOF
echo "Checking for obsessive-compulsive compiler options..." >> configure.log
if try $CC -c $CFLAGS $test.c; then
:
else
echo "Compiler error reporting is too harsh for $0 (perhaps remove -Werror)." | tee -a configure.log
leave 1
fi
Its not clear to me what exactly is being judged too harsh (especially since -Werror is not present). I also don't quite understand what the sample program used in the test is doing, so its not clear to me what the criteria is for judging the compiler warnings "too harsh".
What is zlib complaining is too harsh?
#! /bin/sh
export PATH="/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin:$PATH"
export CC=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
export CXX=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
export LD=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
export AR=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ar
export RANLIB=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib
export CFLAGS="-Wall -Wextra -Wconversion --sysroot="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdks""
export CXXFLAGS="-Wall -Wextra -Wconversion --sysroot="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk""
I had the exact same problem on a newly built machine, and I found the cause was that I didn't actually have the appropriate GNU C compilers installed (reference). Therefore it's complaining that the compiler is too harsh simply because there is no compiler.
Try running:
sudo apt-get install build-essential
and then try running your ./configure again.
My problem was:
cc1: error while loading shared libraries: libimf.so: cannot open shared object file: No such file or directory
Search for details in configure.log.
mine was failing because it tried to use cc (non existent) instead of gcc
is a old question, but i just had this problem compiling zlib 1.2.11 and to bypass this needed to force sudo previous to configure
sudo ./configure --prefix=path

Connecting MYSQL using C program in Eclipse

I am connecting the Mysql using c program in eclipse, I am using CYGWIN compiler to compile program. I have installed the mysql c connector and added the include files to the compiler and linker
but i am getting error
**** Build of configuration Debug for project DbConnectionC ****
make all
Building file: ../connection.c
Invoking: Cygwin C Compiler
gcc -I"C:\Program Files (x86)\MySQL\MySQL Connector C 6.0.2\include" -include"C:\Program Files (x86)\MySQL\MySQL Connector C 6.0.2\include\mysql.h" -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"connection.d" -MT"connection.d" -o "connection.o" "../connection.c"
cygwin warning:
MS-DOS style path detected: D:\java\workspace\DbConnectionC\Debug
Preferred POSIX equivalent is: /cygdrive/d/java/workspace/DbConnectionC/Debug
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
../connection.c: In function `main':
../connection.c:57: warning: char format, different type arg (arg 2)
../connection.c:57: warning: char format, different type arg (arg 2)
../connection.c:61: warning: char format, different type arg (arg 2)
../connection.c:61: warning: char format, different type arg (arg 2)
Finished building: ../connection.c
Building target: DbConnectionC.exe
Invoking: Cygwin C Linker
gcc -L"C:\Program Files (x86)\MySQL\MySQL Connector C 6.0.2\lib\opt" -o "DbConnectionC.exe" ./connection.o -llibmysql.lib -lmysqlclient.lib
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llibmysql.lib
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lmysqlclient.lib
collect2: ld returned 1 exit status
make: *** [DbConnectionC.exe] Error 1
makefile:29: recipe for target `DbConnectionC.exe' failed
**** Build Finished ****
Please help me on this
thanks in advance
In the first part you have some warnings about possible problems:
../connection.c:39: warning: implicit declaration of function `exit'
This means function exit() is not declared, your source needs an #include <stdlib.h>
../connection.c:46: warning: control reaches end of non-void function
You don't return a value at the end of main(), add a return 0; if the program succeeds.
In the second part are linker warnings:
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -llibmysql.lib
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot find -lmysqlclient.lib
which means the linker needs a path to the libraries or the libraries do not exist or the library names are misspelled.
One possible solution is using -lmysql -lmysqlclient instead of -llibmysql.lib -lmysqlclient.lib, but I'm not that familiar with Windows.
Having said that, I suggest strongly, you look at https://stackoverflow.com/tags/c/info and look at some book links.

Display all NVCC warnings in PyCUDA

[update] How can I output the warning messages from compiler.SourceModule(kernel_code)?
With help of #flipchart I was able to pass the right parameters to NVCC trough PyCUDA, but I still don't know, where to access the compiler warnings.
[original question]
Using NVCC directly one can use the compiler switch -Wall*. How would one archive this in pycuda?
I tried mod = compiler.SourceModule(kernel_code,options=['-Wall']), but the error message states:
pytools.prefork.ExecError: error invoking 'nvcc --cubin -Wall -arch sm_11 -I/usr/local/lib/python2.6/dist-packages/pycuda-0.94.2-py2.6-linux-x86_64.egg/pycuda/../include/pycuda kernel.cu': status 255 invoking 'nvcc --cubin -Wall -arch sm_11 -I/usr/local/lib/python2.6/dist-packages/pycuda-0.94.2-py2.6-linux-x86_64.egg/pycuda/../include/pycuda kernel.cu': nvcc fatal : Unknown option 'Wall'
The source problem is, that I spent a whole day debugging, because I overlooked an inexplicit conversion fromfloat to int.
*Warnings from system-header with "--compiler-options -Wall" since CUDA 3.0
The -Wall option is not a nvcc compiler option, but rather one that is passed on to the supporting compiler (g++ or cl.exe). You need to pass in the option --compiler-options -Wall to indicate to nvcc that the option is for the supporting compiler. In you python code:
mod = compiler.SourceModule(kernel_code,options=['--compiler-options','-Wall'])
PyCuda seems to want each option specified as a list item, otherwise it wraps the whole thing in quotes which nvcc doesn't like.