public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
From: ohav chochmah <philomath868@gmail.com>
To: gcc-help@gcc.gnu.org
Subject: some questions about GCC's options
Date: Thu, 31 May 2012 22:14:00 -0000	[thread overview]
Message-ID: <CABOpGfvcfbsb1BZvaHqZjQZaq1EV8QOo9pyMuvdq-PeRs9-LGw@mail.gmail.com> (raw)

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...

             reply	other threads:[~2012-05-31 22:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-31 22:14 ohav chochmah [this message]
2012-06-01  6:21 ` Ian Lance Taylor
2012-06-01  8:00   ` ohav chochmah
2012-06-01  8:04     ` xunxun
2012-06-01  9:44       ` ohav chochmah
2012-06-01 13:15     ` Ian Lance Taylor
2012-06-01 13:44       ` ohav chochmah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABOpGfvcfbsb1BZvaHqZjQZaq1EV8QOo9pyMuvdq-PeRs9-LGw@mail.gmail.com \
    --to=philomath868@gmail.com \
    --cc=gcc-help@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).