I'm building a GHC from source again (7.8 on ARM, as there's no binary version of that), and noticed it does this at some point:
"inplace/bin/ghc-stage1" -static -optc-DTHREADED_RTS -optc-DDEBUG -H32m \
-O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header \
-Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS \
-package-name rts -dcmm-lint -i -irts -irts/dist/build \
-irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen \
-O2 -O0 -c rts/StgMiscClosures.cmm -o rts/dist/build/StgMiscClosures.thr_debug_o
Well, that's -O, -O2 and -O0 in a single command!
What is the reason for this, and which flag takes precedence anyway in such a case?
processArgs processes command-line arguments left-to-right (see process in CmdLineParser.processArgs. Furthermore, the semantics of the -O flags is such that each of them turns on/off a certain subset of individual optimizations (see updOptLevel). So in your example -O0 "wins" since it overwrites the effects of -O and -O2.
Related
I'm getting the next error with llc when trying to to link some IR files:
LLVM ERROR: Cannot select: intrinsic %llvm.objc.clang.arc.use
I discovered that if I disabled clang optimization (O0) during compilation the error doesn't pop up, but I don't want to do that
I attach a sample of how to reproduce it, just cd the 'issue' folder and run the 'issue.sh' to reproduce the error. You must have Xcode (12.x preferred) tu run it
https://drive.google.com/file/d/1j0TvMZI2A7QxRbv_Q7aydtlNYaiTPYBm/view?usp=sharing
This is what the issue.sh contains, that is a reduced version of my real implementation:
echo "clang..."
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x objective-c \
-target arm64-apple-ios12.0 \
-fobjc-arc -fmodules \
-S -Os -flto=thin \
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.1.sdk \
-fembed-bitcode \
-c ${PWD}/GTMSessionFetcher.m \
-o ${PWD}/GTMSessionFetcher.ll
echo "llc..."
${PWD}/llc \
GTMSessionFetcher.ll \
-stats -filetype=obj \
-code-model=small \
-enable-machine-outliner=never \
--mtriple=arm64-apple-ios12.0 \
-o ${PWD}/GTMSessionFetcher.o
As I mentioned before, if you change -Os for -O0, the error disappears, but I do need the size optimization.
The objective-c file that I included is a file from a pod from a Google library
https://github.com/google/gtm-session-fetcher
I found a similar question, but it doesn't have any answer yet
LLVM Error Cannot select intrinsic %llvm.coro.begin
I thought it was bug, but it wasn't
As Akira pointed me in LLVM bug report I was able to fix it by adding an intermediate optimizer OPT step with -objc-arc-contract flag:
clang
...
<path to your LLVM tools>/OPT \
<Your IR file> \
-objc-arc-contract \
-o <Output file>
llc
...
I try to build LLVM.
This is the way I try …
mkdir -p src/llvm-$(LLVM_VERSION).src/build
cd src/llvm-$(LLVM_VERSION).src/build && \
$(CMAKE) -GNinja \
-DCMAKE_INSTALL_PREFIX=$(BUNDLE) \
-DCMAKE_CXX_FLAGS="-D_GLIBCXX_USE_CXX11_ABI=0 -std=c++11 -static-libgcc -static-libstdc++ -l:libstdc++.a" \
-DLLVM_TARGETS_TO_BUILD="X86;NVPTX" \
-DLLVM_PARALLEL_COMPILE_JOBS=$(BUILD_JOBS) \
-DLLVM_PARALLEL_LINK_JOBS=2 \
-DLLVM_USE_CRT_RELEASE=MD \
-DLLVM_USE_CRT_DEBUG=MDd \
-DLLVM_STATIC=ON \
-DLLVM_INCLUDE_TESTS=OFF \
-DLLVM_INCLUDE_EXAMPLES=OFF \
-DLLVM_BUILD_LLVM_C_DYLIB=OFF \
-DLLVM_ENABLE_TERMINFO=OFF \
-DLLVM_ENABLE_UNWIND_TABLES=OFF \
-DLLVM_ENABLE_RTTI=ON \
.. && \
$(CMAKE) --build . && \
$(CMAKE) --build . --target install
You can see -D_GLIBCXX_USE_CXX11_ABI=0 in -DCMAKE_CXX_FLAGS. After LLVM finished compiling, libLLVM*.a still contain abi:cxx11 symbols.
llvm-config reveals, llvm build process completely ignored "-D_GLIBCXX_USE_CXX11_ABI=0" flag.
> ./bundle/bin/llvm-config --cxxflags
-I/home/leonard/Documents/Develop/build_as_deps/bundle/include -std=c++11 -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
Do you have an idea how to build llvm in a way that disables abi:cxx11 symbols and prevents "-D_GLIBCXX_USE_CXX11_ABI=0" to be overridden?
It looks like you're confusing the cmake options (which are specified with via -D) with C/C++ compiler macro (which are also specified via -D, but to compiler). cmake happily ignored your -D_GLIBCXX_USE_CXX11_ABI, because it's not a cmake option (and you should see a warning about this, that the value is unused by the build system).
Since you need to add extra macro definition, you'd need to change CMAKE_CXX_FLAGS cmake variable.
The same project is assembled on different versions of the OS with different flags.
What is this flag?
First OS:
-g++ -c -pipe -g -D_REENTRANT -Wall -W -Wno-unknown-pragmas -DQT_WEBKIT -D_TESTR ...
Other OS:
+g++ -c -pipe -g -D_REENTRANT -Wall -W -Wno-unknown-pragmas -D_TESTR
The -D option is a preprocessor option and is documented in section 3.13 Preprocessor Options of the GCC Manual. (You can also always just run gcc --help or g++ --help to get help for the options.)
The -D<name>[=<value>] option #defines the macro <name> to have the value <value> (or 1 if the value <value> is not provided).
So, in your case, it defines the three macros _REENTRANT, QT_WEBKIT, and D_TESTR to the value 1, in other words, it is exactly equivalent to having
#define _REENTRANT 1
#define QT_WEBKIT 1
#define D_TESTR 1
prepended to the file being compiled.
It's quite easy to get clang++ to use GCC's libstdc++ (-stdlib=stdc++), but how can I do the converse? On OS X Mavericks, the c++ system library is libc++, which means that basically libstdc++ cannot be used (if you mix with other c++ libraries such as boost that have been compiled with libc++). So, roughly, that means G++ is not usable... Unless I can ask it to use libc++ rather than libstdc++.
Thanks.
The script I use (EDIT)
I'm using the following script, g++-libc++, to run g++ on top of libc++, on Mac OS X with MacPorts (hence the -mp names.
#! /bin/sh
clangxx=clang++-mp-3.5
gxx=g++-mp-4.9
libcxx_includes=$($clangxx -print-search-dirs |
perl -ne 's{^libraries: =(.*)}{$1/../../../} && print')
exec $gxx -std=c++11 \
-isystem ${libcxx_includes}/include/c++/v1 \
-nostdinc++ -nodefaultlibs \
-lc -lc++ -lc++abi -lgcc_s.10.5 \
-Wl,-no_compact_unwind \
"$#"
Something like:
g++ -std=c++0x -nostdinc++ -nodefaultlibs -lc -isystem <path_to>/include/c++/v1 -lc++ -lc++abi -lgcc_s.10.5
I am asked to write a Makefile which needs to selects between two compilers, and each of these compilers should support 3 build versions (debug, release, test).
There are a lot of variables that change based on input (compiler, compiler options, output directory, include directories etc). My first option was to go through target-specific variables and configure variables according to target. Do you think this is good idea?
I am not extremely familiar with those kind of variables. It seems to me that if I do something like this:
release: variable1=value1 #release is target
release: variable2=value2
release:
# some compilation rule
Only the variable1 will be configured. Am I right about this?
Update
Thank you for your reply. I am trying to deal with compiler selection issue through additional variable which would be configured according to target. But, here is the problem. I have the following lines:
release: CFLAGS = -DCORE_SW_VERSION='"$(CORE_SW_VERSION)"' -Wall
release: CFLAGS += -fgnu89-inline -mno-volatile-cache $(INCLUDE)
release: TARGET=release
After this lines, I do some ifeq sequence in which I decide which compiler to use (according to TARGET variable value).
And CFLAGS is configured properly, but the TARGET variable is empty. This leads me to conclusion that you can configure only one target-specific variable. Am I right? If not, I am not aware what I am doing wrong. Could you please help me?
Target-specific variables are defined only when building that target and any prerequisites of that target. You can't use target-specific variables arbitrarily throughout the makefile (as it sounds like you're trying to do with ifeq). For that, you may want to look at $(MAKECMDGOALS). I don't believe there is any limit on the number of target-specific variables, certainly not a limit of one.
Needing either target-specific variables or $(MAKECMDGOALS) may be a warning that you're trying to do coerce make into doing something it wasn't meant to do.
It's not clear to me whether you want to build three versions (debug/test/release with a single compiler for each one), or six versions. Assuming three, here is a unix-y Makefile to build with different compilers and CFLAGS depending on the target. However, note that this could just as easily be coded with RELEASE_CFLAGS, RELEASE_CC, DEBUG_CFLAGS, etc... variables.
all: release debug test
release: CC=gcc
release: CFLAGS=
debug: CC=gcc
debug: CFLAGS=-g
test: CC=cc
test: CFLAGS=-Wall
.PHONY: release debug test
release: release/exe
debug: debug/exe
test: test/exe
OBJECTS := test.o
release/%.o: %.c
$(CC) $(CLFAGS) -c -o $# $<
debug/%.o: %.c
$(CC) $(CLFAGS) -c -o $# $<
test/%.o: %.c
$(CC) $(CLFAGS) -c -o $# $<
release/exe: $(OBJECTS:%=release/%)
$(CC) $(CFLAGS) -o $# $^
debug/exe: $(OBJECTS:%=debug/%)
$(CC) $(CFLAGS) -o $# $^
test/exe: $(OBJECTS:%=test/%)
$(CC) $(CFLAGS) -o $# $^