I have built an up-to-date vanilla GCC from svn with these flags:
../configure \
--enable-languages=c,c++ \
--disable-nls \
--enable-multilib \
--prefix=/opt/other/gcc-svn \
--program-suffix=-svn \
--with-system-zlib
First with clang 3.4, then I thought it may be clang's fault (with a grain of salt) and rebuilt GCC once
more with GCC 4.8.1, which led to the exact same result.
The resulting GCC is about 17 seconds slower than GCC 4.8.1 when I try to compile a C++ project with approx. 150k lines of code.
These are the build times I get (-O3):
g++ 4.9: 48 seconds
g++ 4.8: 31 seconds
clang 3.4: 13 seconds
Did I miss a configure flag or is GCC 4.9 really that much slower?!
If the compiler is slower than expected, passing the -ftime-report flag can help figuring out what's going on.
Luckily, it also helped in this case: With -ftime-report GCC printed
'Extra diagnostic checks enabled; compiler may run slowly.
Configure with --enable-checking=release to disable checks.'
Thomas has rebuilt the compiler from source accordingly and the problem is gone!
Related
I have upgraded my whole arch linux system today (12th May, 2022). gcc was also upgraded from v11.2 to v12.1. I tried compiling some of my programs with g++ (part of gcc compiler collection) by the following command:
g++ -O3 -DNDEBUG -Os -Ofast -Og -s -march=native -flto -funroll-all-loops -std=c++20 main.cc -o ./main
The program compiled perfectly and ran as excepted without any errors, but I got a warning:
lto-wrapper: warning: using serial compilation of 2 LTRANS jobs
But, when the same program was compiled using v11.2 it produces zero number of errors and warnings.
My Questions:
What is the meaning of this warning?
How can I fix this?
Is this warning occurred due to upgrading gcc version to v12.1
Here's the g++ configuration on my machine:
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror --with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
Apparently that is a recent change in the -flto option. With a little bit of variation in the google search I was able to find this mail conversation:
Likewise if people just use -flto and auto-detection
finds nothing:
warning: using serial compilation of N LTRANS jobs
note: refer to http://.... for how to use parallel compile
[...]
That is, teach users rather than second-guessing and eventually
blowing things up. IMHO only the jobserver mode is safe to
automatically use.
So this is about using the -flto options correctly. I could not manage to easily get a GCC 12 on my system and thus could not try it myself, but you can try -flto=1 or -flto=auto to get rid of the warning.
Anyway it seems that this warning is rather harmless. It just tells you that GCC uses 2 threads in parallel to do the link time optimization.
The exact semantics and effects of the -flto is (together with the other optimization options) described in detail in the GCC manual. By the way you should not spam optimization options like you do in your command line. For example specifying multiple -O... options will only have the effect of the last one of them. Unless you know exactly what you are doing and have carefully read the manual, just stick to use -O3 and you will be fine.
When I am compiling gcc 8.2 on RHEL 6 (x86-64 arch) I am running into below issue
../../../libgcc/soft-fp/fixtfti.c:33:1: error: unknown type name 'TItype'; did you mean 'TFtype'?
TItype
^~~~~~
TFtype
../../../libgcc/soft-fp/fixtfti.c: In function '__fixtfti':
../../../libgcc/soft-fp/fixtfti.c:38:3: error: unknown type name 'UTItype'; did you mean 'UDItype'?
UTItype r;
^~~~~~~
UDItype
I compiled dependent gmp/mpfr/mpc/binutils/isl successfully and using them in my GCC compilation.
GCC configure command used:
../configure --prefix=/home/zk46w9e/apps/gcc-8.2.0-compliant/compiler/gcc-8.2/ --enable-gold --enable-libssp --enable-vtable-verify --enable-host-shared --enable-lto --with-mpc=/home/zk46w9e/apps/gcc-8.2.0-compliant/mpc/mpc-1.1.0 --with-mpfr=/home/zk46w9e/apps/gcc-8.2.0-compliant/mpfr/mpfr-4.0.1 --with-gmp=/home/zk46w9e/apps/gcc-8.2.0-compliant/gmp/gmp-6.1.2 --with-isl=/home/zk46w9e/apps/gcc-8.2.0-compliant/isl/isl-0.19 --enable-languages=c++ --disable-multilib --disable-nls --enable-threads=posix --enable-tls --enable-__cxa_atexit --enable-plugins
Still running into above issue. Can somebody throw some light?
I tried to compile GCC 32 bit , 64 bit individually by passing flags like -m32 etc which caused above error.
After passing --with-multilib-list=m32,m64 as option for GCC configure and reran the compilation, compilation went fine without any issues
thank you newkid for help
I was trying a tutorial (http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/flens/examples/lapack-geqp3.html) from FLENS-LAPACK.
I have download the src code from the website (https://github.com/michael-lehn/FLENS).
when I try the instruction from the tutorial
g++ -std=c++11 -Wall -I../.. -o lapack-geqp3 lapack-geqp3.cc
I had error from the console:
In file included from lapack-geqp3.cc:2:0:
../../flens/flens.cxx:45:6: error: static assertion failed:
GNU GCC Version 4.7 or higher required! static_assert(__GNUG__>=4 && __GNUC_MINOR__>=7,
I checked the gcc version of my mac
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-apple-darwin14.0.0/5.0.0/lto-wrapper Target: x86_64-apple-darwin14.0.0
Configured with: ../gcc-5-20141005/configure --enable-languages=c++,fortran Thread model: posix
gcc version 5.0.0 20141005 (experimental) (GCC)
It shows that my mac has gcc 5.0.0.
Can anyone tell me what's wrong with the gcc on my mac??
Thanks a lot!!
Noting is wrong with your GCC, the static_assert is wrong.
static_assert(__GNUG__>=4 && __GNUC_MINOR__>=7, ...)
This checks that GCC is both version 4.x or newer, but also minor version 7 or newer. This assertion will only pass on 4.7, 4.8, 4.9, 5.7, 5.8, ... etc.
If the assertion is changed like so:
static_assert(__GNUG__==4 && __GNUC_MINOR__>=7 || __GNUG__>4, ...)
Then it should pass for GCC 5 (assuming it defines __GNUG__ as 5; I have no way of checking at the moment.)
Edit: I've submitted a patch to fix this issue, which has already been accepted and merged. If you pull the latest HEAD, your issue should be fixed.
Under Ubuntu 64 bit I got
llc --version
LLVM (http://llvm.org/):
LLVM version 3.1
Optimized build with assertions.
Built Oct 15 2012 (18:15:59).
Default target: x86_64-pc-linux-gnu
Host CPU: btver1
Registered Targets:
arm - ARM
mips - Mips
mips64 - Mips64 [experimental]
mips64el - Mips64el [experimental]
mipsel - Mipsel
thumb - Thumb
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
I can't do this
clang -march=arm -x c++ /tmp/cpp.cpp
error: unknown target CPU 'arm'
I'm missing something here ? Why I can't compile for ARM ?
-march is LLVM's internal tools command line option and is not connected with clang at all. If you need to compile for other target you need to specify the target triplet. This can be done in several ways (I do not remember offhand, whether they work with 3.1, but they definitely work with 3.2):
Make a link from clang to your-target-triple-clang, e.g. to
arm-none-linux-gnueabi-clang and compile everything via it
Provide -target option, e.g. clang -target arm-none-linux-gnueabi
To get a list of options of the clang compiler, use:
clang -cc1 -help
To specify the target, use -triple:
clang -cc1 -triple "arm-vendor-os" filename
where "vendor" and "os" should be replaced with the actual vendor and OS name. It can also be replaced with unknown.
-triple is a string of the form ARCHITECTURE-VENDOR-OS or ARCHITECTURE-VENDOR-OS-ENVIRONMENT. For example: x86_64-apple-darwin10
the llvm linker links for the host, which is only one of the targets, it wont link to every target in the list. it will definitely compile for any target. Basically clang goes from C/C++ to bytecode, then llc takes bytecode and makes assembly for the specific target (new experrimental option to take the bytecode straight to object file) then you need to get a cross assembler and a cross linker to take it the final mile (I use gnu binutils). Unfortunately I found that clang to bytecode is not completely generic (I had hoped and expected that it would be), it does in fact change the target independent output based on the target. The example below using the host triple instead of using -march allowed for my examples to build properly on more hosts.
ARMGNU?=arm-none-eabi
LOPS = -Wall -m32 -emit-llvm -ccc-host-triple $(ARMGNU)
OOPS = -std-compile-opts
LLCOPS = -march=thumb -mtriple=$(ARMGNU)
clang $(LOPS) -c blinker03.c -o blinker03.clang.bc
opt $(OOPS) blinker03.clang.bc -o blinker03.clang.thumb.opt.bc
llc $(LLCOPS) blinker03.clang.thumb.opt.bc -o blinker03.clang.thumb.opt.s
$(ARMGNU)-as blinker03.clang.thumb.opt.s -o blinker03.clang.thumb.opt.o
$(ARMGNU)-ld -o blinker03.clang.thumb.opt.elf -T memmap vectors.o blinker03.clang.thumb.opt.o
I have not, but before long will experiment with using the llc straight to object (actually I tried it on a simple test but have not used it on anything larger or posted it anywhere).
You're confusing your flags. clang's -march= wants a processor family. You probably meant to use clang -arch arm instead.
As this comment says this option it's not supported yet under linux, for now.
"-arch arm" is equivalent to "-arch armv4t" in clang. I suppose that a generic "arm" target is not allowed with "-march=", which should require something more precise, such as "armv6", "thumbv7", "armv4t", ...
Try selecting a specific subarch.
Starting Clang 11 (trunk), the list of supported target architectures could be handily printed using the newly added -print-targets flag.
I'm trying to get crosstool-ng working with both C and C++. Even though I've selected C++ while using menuconfig, it doesn't seem to get built. The gcc compiler works as expected but not g++
I'm not sure what I'm doing wrong so any help would be appreciated.
I followed the steps found here:
Building embedded ARM systems with Crosstool-NG
$ arm-unknown-linux-gnueabi-cpp main.cpp -o test
arm-unknown-linux-gnueabi-cpp: main.cpp: C++ compiler not installed on this system
NOTE: there is no arm-unknown-linux-gnueabi-g++ found on in the bin directory.
I've tried cross-tool version 1.16.0 and 1.15.3
arm-unknown-linux-gnueabi-cpp -v
Using built-in specs.
Target: arm-unknown-linux-gnueabi
Configured with: /opt/crossArm/.build/src/gcc-4.3.2/configure --build=i686-build_pc-linux-gnu --host=i686-build_pc-linux-gnu --target=arm-unknown-linux-gnueabi --prefix=/opt/crossArm/.build/arm-unknown-linux-gnueabi/buildtools --with-local-prefix=/home/jgarvin/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot --disable-libmudflap --with-sysroot=/home/jgarvin/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sysroot --enable-shared --with-pkgversion='crosstool-NG 1.16.0' --with-float=soft --enable-__cxa_atexit --with-gmp=/opt/crossArm/.build/arm-unknown-linux-gnueabi/buildtools --with-mpfr=/opt/crossArm/.build/arm-unknown-linux-gnueabi/buildtools --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-nls --disable-multilib --enable-languages=c
Thread model: posix
gcc version 4.3.2 (crosstool-NG 1.16.0)
Code
#include<iostream>
using namespace std;
int main(){
cout<<"Hello World"<<endl;
return 0;
}
In my build.log file I see C++ option turned on
[DEBUG] CT_CC_SUPPORT_CXX=y
I also see it in the config.log:
configure:3030: $? = 0
configure:3019: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
From, http://briolidz.wordpress.com/2012/02/07/building-embedded-arm-systems-with-crosstool-ng/
Refine your configuration by running the menuconfig interface:
$ ./ct-ng menuconfig
In this step, navigate to the C Compiler menu. Then you can select C++ or de-select Java, Fortran, etc. Since crosstool-ng is just a bunch of scripts and patch files, it is very rare that a development build breaks things. You can always pull from the hg repository.
hg clone http://crosstool-ng.org/hg/crosstool-ng
cd crosstool-ng
./bootstrap
make
sudo make install
This will have the latest fixes. I have built arm cross compilers with C++ support many times using this method [including Canadian crosses for Mingw and i386 from an x86_64 host].
EDIT: I see that the wordpress link recommends a local install of ct-ng. The commands above do a full install, putting things in /usr/local. Also, it seems the OP did try to set menuconfig's C++ option. Try altering the sjlj value, use the latest version of ct-ng and install it. This produces an ARM Linux C++ cross-compiler on Ubuntu for me. The build.log output can be helpful in determining if ct-ng decided some configuration was impossible.
Finally, the mailing list crossgcc#sourceware.org doesn't require subscription afaik. The archives at http://sourceware.org/ml/crossgcc/ can be helpful. If you still have issues, I am sure someone on the mailing list will be able to help you.
EDIT: With the latest ct-ng installed try,
$ ct-ng arm-cortex_a15-linux-gnueabi #Alternate arm-yem-linux-gnueabi
$ ct-ng menuconfig # Tweak for your processor, gcc version, etc.
$ ct-ng build # Go have a coffee (or work on something else).
Sorry, your host compiler was made with Linaro. I was reading too much into your edit.
I was having similar issue. It turns out that I was looking at the wrong bin directory under .build. The final version of the toolchain was installed under ~/x-tools instead...
If you are still looking for an answer on compiling c++ on arm platform:
Install crosstool-ng:
tar xjf <ct-ng archive>
cd crosstool-ng-<numversion>
# reset of LD_LIBRARY_PATH is required to avoid issues with crosstool-ng
unset LD_LIBRARY_PATH
./configure prefix=<installDir>
#example ./configure prefix=/opt/cross-rpi
make
make install
#required to make sure you get the right on in case
export PATH=<installDir>/bin:$PATH
#check what version is on now.
which ct-ng
Now create and launch the configuration:
mkdir chain-build #the directory hosting the build files of your cross compil chain
cd chain-build
ct-ng menuconfig
Set options are relevant to the arm platform amongst other:
Paths and misc Options
Configure the maximum log level to see to WARN instead of INFO which totally clutters the logs and in my opinion makes them hard to use, way too much noise for the usual use case.
Target options Operating System
Target Architecture
arm
System
linux
Binary utilities
- Select the last version of binutils
C compiler
GCC : Select Show linaro Versions then select the lastest linaro gcc (more stable than non linaro, from experience)
C++ : Check it
Now build your toolchain
ct-ng build
# once done check the content of the bin dir
ls <yourChainInstallDir>/x-tools/arm-unknown-linux-gnueabi/bin
You should get something like this:
of all to compile c++ code you should only need g++. To check if g++ (for arm) works ok type
arm-unknown-linux-gnueabi-g++ -v
You should get something similar to this:
Using built-in specs.
COLLECT_GCC=x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-g++
COLLECT_LTO_WRAPPER=/opt/cross1.19/x-tools/arm-unknown-linux-gnueabi/libexec/gcc/arm- unknown-linux-gnueabi/4.8.2/lto-wrapper
Target: arm-unknown-linux-gnueabi
[...]
blahblah
[...]
gcc version 4.8.2 20130603 (prerelease) (crosstool-NG 1.19.0)
Once you get this message you should be ok.
The only other thing to watch out for is if you got all of the libraries needed to compile your code.
e.g. for instance on Raspberry-pi (using Raspbian), some of the libs have to be manually imported from /lib and /usr/lib (put then in your LD_LIBRARY_PATH).
Sometimes the includes for gcc or g++ are not copied in the include directory of the toolchain (when using crosstool-ng, got the issue a couple of times), so you need to get the includes from your /usr/include directory.