some questions about GCC's options

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



hello all,
I have been playing with the command-line options recently, and I'l
appreciate answers, if someone has got time.

~ $ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120505/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++
--enable-shared --enable-threads=posix --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions
--enable-clocale=gnu --disable-libstdcxx-pch --enable-libstdcxx-time
--enable-gnu-unique-object --enable-linker-build-id --with-ppl
--enable-cloog-backend=isl --enable-lto --enable-gold
--enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--with-linker-hash-style=gnu --disable-multilib --disable-libssp
--disable-build-with-cxx --disable-build-poststage1-with-cxx
--enable-checking=release
Thread model: posix
gcc version 4.7.0 20120505 (prerelease) (GCC)

~ $ grep 'model name' /proc/cpuinfo
model name	: Intel(R) Core(TM) i3 CPU       M 350  @ 2.27GHz

first, is momit-leaf-frame-pointer bad for debugging (in the way
fomit-frame-pointer can be)?, if not, why is it disabled by default
even when optimizing (as -Q --help=target | grep omit reveals)?
next, the manual mentions that fno-fat-lto-objects improves
compilation time over plain LTO, but requires the whole toolchain to
be aware of LTO and support plugins, which is why it's not (yet) the
default.  how can I know for certain if the toolchain I'm using meets
the criteria (seems to be the case)?
similarly, mtls-dialect=gnu2 is better then the default gnu, "but it
may add compile- and run-time requirements that cannot be satisfied on
all systems."  how can I test for them?
is it true that mfpmath=sse can result in poor code when using glibc?
(maybe I shouldn't ask that here...)
why is msse disabled by default even after march=native, while
msse[234], msse4.[12] and mssse3 are all enabled?
isn't the CRC32 instruction part of sse4.2?, why is mcrc32 disabled by
default even when sse4.2 is enabled?

thanks in advance, and sorry for bothering...


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux