I've tried looking at the documentation for g++, didn't find this.
Is there a compiler setting I can use to check for use of the free-store?
Related
What I'm doing I'm developing an R interface/package for C++ codes with Rcpp and CMake. Because openmp and c++11 should be supported, so I have a preference on compilers.
Problem I know that I can always put Makevars under ~/.R (Unix) to change the compiler R uses when install packages. But as a developer, it is not recommended to do so.
It is recommended to use configure file to do that. However, I don't quite know how to achieve this, because I'm writing configure file by myself and calling cmake inside my configure. I don't know what to write in configure file to search for a specific compiler.
Hope the description is clear. Thank you.
I have attached my configure file content below.
```
set -x
set -e
which cmake
rm -rf _builds
# call cmake that will set compiler flags in src/Makevars
# and download dependencies
cmake -H. -B_builds
```
I've been using CMake for building R packages for quite a while, see https://github.com/rohan-shah/mpMap2 for an example.
I completely bypass the R build system though, so I don't use configure at all.
As I understand, you want to detect if the compiler supports openmp and C++11.
There are many existing packages using configure to detect openmp support. One example is ARTP2 (https://github.com/zhangh12/ARTP2/blob/master/configure.ac), which has been mentioned in the "Writing R extension" as an example. You can also use the configure script in xgboost by me (https://github.com/dmlc/xgboost/blob/master/R-package/configure.ac) as an example. We leave OPENMP_CXXFLAGS blank if the compiler doesn't support openmp.
For C++11 support, you can try AX_CXX_COMPILE_STDCXX_11. But this will require a new version of autoconf.
I think you can also try AC_PROG_CXX to select compilers, like icc.
I'm new to Gentoo and trying to install a 3D modelling program called TexGen (http://texgen.sourceforge.net/index.php/Main_Page) using CMake, and I keep getting the error:
relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
This occurs during the step:
[ 80%] Linking CXX shared module ../_Renderer.so
I've looked all over and tried setting the -fPIC flag in the cmake options file, but there's no change in the result. As I said I'm quite new (in the order of a few weeks) to Linux and Gentoo and any help would be greatly appreciated.
Actually Gentoo has a eclass(es) to build CMake based projects (see /usr/portage/cmake*.eclass). And AFAIK, it replace package options with yours (to be precise, it adds a new configuration type), configured in /etc/portage/make.conf (or /etc/paludis/bashrc if you use paludis). So, I not wondered that "hacking" CMakeLists.txt in the package ebuild do not help.
So, easiest way is to add that option to your Gentoo settings instead. Personaly I use this way to build boost library in my system (yep, I need boost's static libraries to be linked into dynamic one in some of my projects). And yes, I'm using paludis, but emerge probably has similar feature (a way to set per package compiler options).
The other way, instead of "hacking" compiler options directly (via CMAKE_<LANG>_FLAGS), take a look to CMAKE_POSITION_INDEPENDENT_CODE -- it'll add a proper compiler option for you, and probably eclass' manipulations with cache wouldn't affect this setting.
I got it to work (for installing ffmpeg) by simply reinstalling the whole thing from the beginning with all instances of $ ./configure replaced by $ ./configure --enable-shared (first make sure to delete all the folders and files including the .so files from the previous attempt).
Apparently this works because https://stackoverflow.com/a/13812368/10593190.
In the 2.x version of CMake, the cmake option CMAKE_BUILD_TYPE controlled options to be passed to the compiler. For example, if CMAKE_BUILD_TYPE=RelWithDebInfo then the options passed to the compiler was CMAKE_CXX_FLAGS_RELWITHDEBINFO for C++ and CMAKE_C_FLAGS_RELWITHDEBINFO for C (http://binglongx.wordpress.com/tag/cmake_build_type/).
In the new 3.x version of CMake there are commands add_compile_options and target_compiler_options for adding options to the compiler (What is the modern method for setting general compile flags in CMake?).
Questions
How do I define which build type CMake should use? Is it still, for example, cmake -DCMAKE_BUILD_TYPE=Debug?
How do I make use of this build type in my CMakeLists.txt?
Has CMake defined all the build types, or can I define custom, additional, build types?
Has CMake set any default compiler options for each of the build types (for example -g for the Debug build type)?
Please try to stick to a single question per question in the future. You might risk getting closed as too broad otherwise. Also, you are more likely to get good answers for well-defined, precise questions.
How do I define which build type CMake should use? Is it still, for
example, cmake -DCMAKE_BUILD_TYPE=Debug?
Yes, this did not change.
How do I make use of this build type in my CMakeLists.txt?
Use generator expressions. For example:
target_compile_options(my_program PUBLIC $<$<CONFIG:Debug>:-Werror>)
# Warnings are errors for debug build only
Has CMake defined all the build types, or can I define custom,
additional, build types?
You can add your own type if the defaults don't cut it for you. Note though that this can be a bit fiddly, so I wouldn't do it unless you have good reasons. Take a look at CMAKE_CONFIGURATION_TYPES.
Has CMake set any default compiler options for each of the build types
(for example -g for the Debug build type)?
CMake does a pretty good job at choosing the right defaults for the different configurations. In particular, Debug and RelWithDebInfo builds generate symbols correctly (-g on gcc) and Release builds are optimized quite well.
Context: I have several loops in an Objective-C library I am writing which deal with processing large text arrays. I can see that right now it is running in a single threaded manner.
I understand that LLVM is now capable of auto-vectorising loops, as described at Apple's session at WWDC. It is however very cautious in the way it does it, one reason being the possibility of variables being modified due to CPU pipelining.
My question: how can I see where LLVM has vectorised my code, and, more usefully, how can I receive debug messages that explain why it can't vectorise my code? I'm sure if it can see why it can't auto-vectorise it, it could point that out to me and I could make the necessary manual adjustments to make it vectorisable.
I would be remiss if I didn't point out that this question has been more or less asked already, but quite obtusely, here.
Identifies loops that were successfully vectorized:
clang -Rpass=loop-vectorize
Identifies loops that failed vectorization and indicates if vectorization was specified:
clang -Rpass-missed=loop-vectorize
Identifies the statements that caused vectorization to fail:
clang -Rpass-analysis=loop-vectorize
Source: http://llvm.org/docs/Vectorizers.html#diagnostics
The standard llvm toolchain provided by Xcode doesn't seem to support getting debug info from the optimizer. However, if you roll your own llvm and use that, you should be able to pass flags as mishr suggested above. Here's the workflow I used:
1. Using homebrew, install llvm
brew tap homebrew/versions
brew install llvm33 --with-clang --with-asan
This should install the full and relatively current llvm toolchain. It's linked into /usr/local/bin/*-3.3 (i.e. clang++-3.3). The actual on-disk location is available via brew info llvm33 - probably /usr/local/Cellar/llvm33/3.3/bin.
2. Build the single file you're optimizing, with homebrew llvm and flags
If you've built in Xcode, you can easily copy-paste the build parameters, and use your clang++-3.3 instead of Xcode’s own clang.
Appending -mllvm -debug-only=loop-vectorize will get you the auto-vectorization report. Note: this will likely NOT work with any remotely complex build, e.g. if you've got PCH's, but is a simple way to tweak a single cpp file to make sure it's vectorizing correctly.
3. Create a compiler plugin from the new llvm
I was able to build my entire project with homebrew llvm by:
Grabbing this Xcode compiler plugin: http://trac.seqan.de/browser/trunk/util/xcode/Clang%20LLVM%20MacPorts.xcplugin.zip?order=name
Modifying the clang-related paths to point to my homebrew llvm and clang bin names (by appending '-3.3')
Placing it in /Library/Application Support/Developer/5.0/Xcode/Plug-ins/
Relaunching Xcode should show this plugin in the list of available compilers. At this point, the -mllvm -debug-only=loop-vectorize flag will show the auto-vectorization report.
I have no idea why this isn't exposed in the Apple builds.
UPDATE: This is exposed in current (8.x) versions of Xcode. The only thing required is to enable one or more of the loop-vectorize flags.
Assuming you are using opt and you have a debug build of llvm, you can do it as follows:
opt -O1 -loop-vectorize -debug-only=loop-vectorize code.ll
where code.ll is the IR you want to vectorize.
If you are using clang, you will need to pass the -debug-only=loop-vectorize flag using -mllvm option.
Unfortunately, I'm having trouble compiling the GNUstep Startup package. This requires an edit in the LD_LIBRARY_PATH variable which I'm unfamiliar with. Some reading up on it didn't quite tell me what I would need to do to implement a particular solution for this. Is there anyone who knows what this means exactly? The message is a little cryptic to me.
I don't seem to be able to use your Objective-C compiler to produce
working binaries! Please check your Objective-C compiler installation.
For gcc-3.0.x make sure that your compiler's libgcc_s and libobjc
can be found by the dynamic linker - usually that requires you to add
the directory given by gcc -print-file-name=libobjc.so to your
LD_LIBRARY_PATH or /etc/ld.so.conf.
Please refer to your compiler installation instructions for more help.
export LD_LIBRARY_PATH=/path/to/what/you/want