C++ compilers have an option to warn against writing a || b && c without parentheses (clang and gcc do this automatically on -Wall, the specific option in clang is called -Wlogical-op-parentheses). Is there an analogous feature in rustc?
Related
I am looking to enable compiler options for Rust applications built on Windows using the MSVC toolchain. I see that rustc provides the option "-C llvm-args" to provide flags to the LLVM toolchain but I don't see such an option for MSVC. Does this support currently exist for rustc or cargo?
Rustc is the Rust compiler and it relies on the LLVM backends for actual code generation on all platforms. So if you need to pass arguments to the backend, you can use -C llvm-args on Windows like in other platforms.
The distinction between the MSVC toolchain or the MINGW toolchain mostly concerns the linker. Options can be passed to the linker with -C link-arg or -C link-args on all platforms, although of course in this case the available options will depend on the targeted toolchain.
I stumbled upon a problem which I couldn’t immediately solve by reading the documentation of FindBLAS and FindOpenMP. Maybe someone here has a hint for me.
Let’s say I have project which imports an interface target A with BLAS dependency. FindBLAS determines MKL to be a good fit. Now, in my CMakeLists.txt I construct another target B which requires OpenMP. Then I link A to be B.
My concrete problem is that on Linux with GCC as compiler FindBLAS uses Intel’s OpenMP implementation and sets MKL’s interface layer accordingly (which is also what is suggested by the MKL Link Advisor).
FindOpenMP of course falls back to libgomp for linking. During linking I then end up using both runtime libraries, i.e. libgomp and libiomp, which I find somewhat dangerous. Here a reduced CMakeLists.txt that illustrates the problem:
cmake_minimum_required(VERSION 3.12)
project(test LANGUAGES C CXX)
find_package(BLAS REQUIRED)
find_package(OpenMP REQUIRED)
# Dummy interface libary A that depends on MKL
add_library(a INTERFACE)
target_include_directories(a INTERFACE include/)
target_link_libraries(a INTERFACE "${BLAS_LIBRARIES}")
target_link_options(a INTERFACE "${LINKER_FLAGS}")
# target B that depends on OpenMP and A
add_executable(b src/b.cc)
target_link_libraries(b PRIVATE OpenMP::OpenMP_CXX a)
Output is as follows:
– The C compiler identification is GNU 9.1.0
– The CXX compiler identification is GNU 9.1.0
– Check for working C compiler: /opt/bwhpc/common/compiler/gnu/9.1.0/bin/gcc
– Check for working C compiler: /opt/bwhpc/common/compiler/gnu/9.1.0/bin/gcc – works
– Detecting C compiler ABI info
– Detecting C compiler ABI info - done
– Detecting C compile features
– Detecting C compile features - done
– Check for working CXX compiler: /opt/bwhpc/common/compiler/gnu/9.1.0/bin/g++
– Check for working CXX compiler: /opt/bwhpc/common/compiler/gnu/9.1.0/bin/g++ – works
– Detecting CXX compiler ABI info
– Detecting CXX compiler ABI info - done
– Detecting CXX compile features
– Detecting CXX compile features - done
– Looking for sgemm_
– Looking for sgemm_ - not found
– Looking for pthread.h
– Looking for pthread.h - found
– Looking for pthread_create
– Looking for pthread_create - not found
– Looking for pthread_create in pthreads
– Looking for pthread_create in pthreads - not found
– Looking for pthread_create in pthread
– Looking for pthread_create in pthread - found
– Found Threads: TRUE
– Looking for sgemm_
– Looking for sgemm_ - found
– Found BLAS: /opt/bwhpc/common/compiler/intel/compxe.2018.5.274/compilers_and_libraries_2018.5.274/linux/mkl/lib/intel64_lin/libmkl_intel_lp64.so;/opt/bwhpc/common/compiler/intel/compxe.2018.5.274/compilers_and_libraries_2018.5.274/linux/mkl/lib/intel64_lin/libmkl_intel_thread.so;/opt/bwhpc/common/compiler/intel/compxe.2018.5.274/compilers_and_libraries_2018.5.274/linux/mkl/lib/intel64_lin/libmkl_core.so;/opt/bwhpc/common/compiler/intel/compxe.2018.5.274/compilers_and_libraries_2018.5.274/linux/compiler/lib/intel64_lin/libiomp5.so;-lpthread;-lm;-ldl
– Found OpenMP_C: -fopenmp (found version “4.5”)
– Found OpenMP_CXX: -fopenmp (found version “4.5”)
– Found OpenMP: TRUE (found version “4.5”)
– Configuring done
– Generating done
And building yields:
$ VERBOSE=1 make
/pfs/data1/software_uc1/bwhpc/common/devel/cmake/3.14.0/bin/cmake -S/home/hd/hd_hd/hd_em426/psidm2 -B/home/hd/hd_hd/hd_em426/psidm2/build --check-build-system CMakeFiles/Makefile.cmake 0
/pfs/data1/software_uc1/bwhpc/common/devel/cmake/3.14.0/bin/cmake -E cmake_progress_start /home/hd/hd_hd/hd_em426/psidm2/build/CMakeFiles /home/hd/hd_hd/hd_em426/psidm2/build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory /pfs/data2/home/hd/hd_hd/hd_em426/psidm2/build' make -f CMakeFiles/b.dir/build.make CMakeFiles/b.dir/depend make[2]: Entering directory /pfs/data2/home/hd/hd_hd/hd_em426/psidm2/build’
cd /home/hd/hd_hd/hd_em426/psidm2/build && /pfs/data1/software_uc1/bwhpc/common/devel/cmake/3.14.0/bin/cmake -E cmake_depends “Unix Makefiles” /home/hd/hd_hd/hd_em426/psidm2 /home/hd/hd_hd/hd_em426/psidm2 /home/hd/hd_hd/hd_em426/psidm2/build /home/hd/hd_hd/hd_em426/psidm2/build /home/hd/hd_hd/hd_em426/psidm2/build/CMakeFiles/b.dir/DependInfo.cmake --color=
Dependee “/home/hd/hd_hd/hd_em426/psidm2/build/CMakeFiles/b.dir/DependInfo.cmake” is newer than depender “/home/hd/hd_hd/hd_em426/psidm2/build/CMakeFiles/b.dir/depend.internal”.
Dependee “/home/hd/hd_hd/hd_em426/psidm2/build/CMakeFiles/CMakeDirectoryInformation.cmake” is newer than depender “/home/hd/hd_hd/hd_em426/psidm2/build/CMakeFiles/b.dir/depend.internal”.
Scanning dependencies of target b
make[2]: Leaving directory /pfs/data2/home/hd/hd_hd/hd_em426/psidm2/build' make -f CMakeFiles/b.dir/build.make CMakeFiles/b.dir/build make[2]: Entering directory /pfs/data2/home/hd/hd_hd/hd_em426/psidm2/build’
[ 50%] Building CXX object CMakeFiles/b.dir/src/b.cc.o
/opt/bwhpc/common/compiler/gnu/9.1.0/bin/g++ -I/home/hd/hd_hd/hd_em426/psidm2/include -fopenmp -o CMakeFiles/b.dir/src/b.cc.o -c /home/hd/hd_hd/hd_em426/psidm2/src/b.cc
[100%] Linking CXX executable b
/pfs/data1/software_uc1/bwhpc/common/devel/cmake/3.14.0/bin/cmake -E cmake_link_script CMakeFiles/b.dir/link.txt --verbose=1
/opt/bwhpc/common/compiler/gnu/9.1.0/bin/g++ CMakeFiles/b.dir/src/b.cc.o -o b /pfs/data1/software_uc1/bwhpc/common/compiler/gnu/9.1.0/lib64/libgomp.so -lpthread -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core /opt/bwhpc/common/compiler/intel/compxe.2018.5.274/compilers_and_libraries_2018.5.274/linux/compiler/lib/intel64_lin/libiomp5.so -lpthread -lm -ldl
So I guess my question is: Is this the intended behaviour of FindBLAS? Wouldn’t it be better for FindBLAS to select MKL’s GNU interface and use libgomp if it detects a GNU compiler so that mixing with FindOpenMP results not in the problem discussed above?
The LLVM (and Intel) OpenMP runtime has shims that allow GCC compiled OPenMP code to run with it*. Therefore your best solution is likely to do that: link with libiomp5 everywhere.
You are absolutely right to avoid having both libraries in the process. That can lead to over-subscription (more threads than logicalCPUs) and poor performance aside from potential incorrect execution.
* There may be issues if you are using offload to other devices such as GPUs, but for CPU only code GCC compatibility is a critical aim for the LLVM/Intel runtime, precisely so that you can easily solve this problem.
I am trying to build Microsoft's Bond.
First CMake could not find my Boost. After I removed the OPTIONAL_COMPONENTS from find_package (Boost ... ) in Config.cmake cmake found my Boost.
Now I am getting this output error after make
Scanning dependencies of target gbc
[ 9%] Generating build/gbc/gbc
Invalid package ID: "array-0.5.1.1 base-4.9.0.0 binary-0.8.3.0 bytestring-0.10.8.1"
CMake Error at stack_build.cmake:32 (message):
compiler/CMakeFiles/gbc.dir/build.make:100: recipe for target 'compiler/build/gbc/gbc' failed
make[2]: *** [compiler/build/gbc/gbc] Error 1
CMakeFiles/Makefile2:172: recipe for target 'compiler/CMakeFiles/gbc.dir/all' failed
make[1]: *** [compiler/CMakeFiles/gbc.dir/all] Error 2
Makefile:138: recipe for target
What I the exact same thing what the documents says. I installed all dependencies and made this.
mkdir build
cd build
cmake -DBOND_ENABLE_GRPC=FALSE ..
make
sudo make install
Output is.
-- The C compiler identification is GNU 7.2.0
-- The CXX compiler identification is GNU 7.2.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PythonInterp: /usr/bin/python2.7 (found suitable version "2.7.12", minimum required is "2.7")
-- Found PythonLibs: /usr/lib/x86_64-linux-gnu/libpython2.7.so (found suitable version "2.7.12", minimum required is "2.7")
-- Boost version: 1.61.0
-- Boost Python Library:
-- Stack found at /usr/bin/stack. Version 0.1.10.0 x86_64
-- Configuring done
-- Generating done
-- Build files have been written to: /home/berkan/Documents/programming/bond/build
We've seen this happen when the version of the Haskell Stack tool (stack) is older than 1.5.1. If you upgrade Haskell Stack to a newer version, this problem should go away.
The gbc tool that is part of Bond is written in Haskell, so to build it from source you will need to have a working Haskell Stack toolchain.
Briefly, for Linux, to upgrade an existing version:
$ stack upgrade
(To install Stack fresh, curl -sSL https://get.haskellstack.org/ | sh.)
There's a similar issue that someone else encountered in the Bond project's issue list. This fix there was to use a newer version of the Haskell Stack tool.
I am working on a Haskell program which is linked to some old C++ code. I created a C interface and got it working with ghc only. Now I tried to convert the used Makefile into a Cabal project and now cabal on the last step selects the wrong linker.
Because of some dependencies I have to use a quite old ghc and gcc. So what I am doing is calling cabal (1.24.0.0.) like this:
cabal install --with-ghc=ghc-7.6.3 --with-gcc=/opt/gcc-3.3.6/bin/gcc --with-ld=/opt/gcc-3.3.6/bin/gcc
For the compile- and intermediate configure linking all is ok, with -v3 I get the following lines:
Using gcc version 3.3.6 given by user at: /opt/gcc-3.3.6/bin/gcc
Using ghc version 7.6.3 given by user at: /home/oswald/ghcs/bin/ghc-7.6.3
...
Using ld given by user at: /opt/gcc-3.3.6/bin/gcc
All works fine until the final linking step:
Linking dist/dist-sandbox-c45ed4c7/build/MISCconfig/MISCconfig ...
*** C Compiler:
'/opt/gcc-3.3.6/bin/gcc' '-c' '/tmp/ghc28340_0/ghc28340_0.c' '-o' ...
*** C Compiler:
'/opt/gcc-3.3.6/bin/gcc' '-c' '/tmp/ghc28340_0/ghc28340_0.s' '-o' ...
*** Linker:
'/usr/bin/gcc' '-fno-stack-protector' '-Wl,--hash-size=31' '-W
So the last line specifies /usr/bin/gcc as the linker, which is the system one and therefore I get link errors where it should be /opt/gcc-3.3.6/bin/gcc (have to use a pre-3.4.0 gcc because of link compatibility for one of the used C++ libraries and gcc 3.3.6 is the latest with the old ABI).
So what I am doing wrong? Cabal says it selects the linker from the old gcc but then actually uses the newer one from the system?
When I just use ghc with the -pgmc /opt/gcc-3.3.6/bin/gcc switch in a makefile all works but I would prefer to get a cabal sandbox working...
This apparently had nothing to do with Cabal, which does not instruct GHC to use the C compiler specified by the Cabal option --with-gcc.
Use -pgml to select the linker as documented on the GHC man page.
(One point that may cause confusion for others and is worth mentioning. GHC always uses a C compiler to do the final link step. That means -pgml must refer to something like gcc, not something like ld. Consequently flags intended to be consumed by ld such as -rpath must be prefixed by -Wl, before being fed to -optl.)
In Linux gcc version 4.1.2 I am getting error "cc: unrecognized option '-Xa'". Any idea about this compiler option '-Xa' . However it gets compiled in solaris gcc 3.4.3 version.
Howerver, the ouput is "cc...". Are you sure you are using gcc. not other compiler(e.g SUN cc) ?
You can install gcc on Solaris, HPUX, AIX etc. but you typically cannot install the proprietary cc compilers in other environments, including linux.
-Xa is a Sun C compiler option.
From Man Page cc.1:
-X[c|a|t|s]
Specifies the degree of conformance to the ISO C stan-
dard[...]
a This is the default compiler mode. ISO C plus K&R
C compatibility extensions, with semantic changes
required by ISO C. Where K&R C and ISO C specify
different semantics for the same construct, the
compiler uses the ISO C interpretation. If the -Xa
option is used in conjunction with the -xtransi-
tion option, the compiler issues warnings about
the different semantics. The predefined macro
__STDC__ has a value of 0 with the -Xa option.