From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8001 invoked by alias); 1 Jun 2012 08:04:04 -0000 Received: (qmail 7988 invoked by uid 22791); 1 Jun 2012 08:04:02 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_NX X-Spam-Check-By: sourceware.org Received: from mail-pz0-f47.google.com (HELO mail-pz0-f47.google.com) (209.85.210.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 01 Jun 2012 08:03:29 +0000 Received: by dalh21 with SMTP id h21so2385440dal.20 for ; Fri, 01 Jun 2012 01:03:28 -0700 (PDT) Received: by 10.68.226.226 with SMTP id rv2mr8767213pbc.101.1338537808552; Fri, 01 Jun 2012 01:03:28 -0700 (PDT) Received: from [192.168.1.100] ([58.248.98.130]) by mx.google.com with ESMTPS id py5sm1965786pbb.1.2012.06.01.01.03.23 (version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 01:03:26 -0700 (PDT) Message-ID: <4FC876E2.5050706@gmail.com> Date: Fri, 01 Jun 2012 08:04:00 -0000 From: xunxun User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: ohav chochmah CC: Ian Lance Taylor , gcc-help Subject: Re: some questions about GCC's options References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2012-06/txt/msg00002.txt.bz2 于 2012/6/1 15:59, ohav chochmah 写道: > On 6/1/12, Ian Lance Taylor wrote: >> ohav chochmah writes: >> >>> first, is momit-leaf-frame-pointer bad for debugging (in the way >>> fomit-frame-pointer can be)? >> It's not as bad. It may still trip up some debuggers. >> > but not GDB? > >>> if not, why is it disabled by default >>> even when optimizing (as -Q --help=target | grep omit reveals)? >> When optimizing on x86 or x86_64, -fomit-frame-pointer is the default >> anyhow. -fomit-frame-pointer essentially implies >> -momit-leaf-frame-pointer. >> > I was sure that's the answer, but then is GCC lying to me? > ~ $ gcc -S tst.c -O2 -march=native -Q --help=optimizers | grep omit > -fomit-frame-pointer [disabled] x86 or x86_64? I remembered -fomit-frame-pointer enabled only on x86_64 by default. > >>> 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)? >> Use the most recent GNU binutils release. >> > good then, thanks. > >>> 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? >> Build a program with it and see. Basically your GNU binutils need to be >> fairly new and your glibc needs to be 2.9 or later. >> > good, thanks. >>> is it true that mfpmath=sse can result in poor code when using glibc? >>> (maybe I shouldn't ask that here...) >> For x86_64 -mfpmath=sse is the default. >> > here again: > ~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep 'mfpmath=' > -mfpmath= 387 > >>> why is msse disabled by default even after march=native, while >>> msse[234], msse4.[12] and mssse3 are all enabled? >> Not sure--what makes you think this is the case? >> > sorry, 's/msse/mmmx/'. > ~ $ gcc -S tst.c -O2 -march=native -Q --help=target | grep mmx > -mmmx [disabled] > > ~ $ sudo x86info -a -v | grep -i mmx > mmx MMX support > >>> isn't the CRC32 instruction part of sse4.2?, why is mcrc32 disabled by >>> default even when sse4.2 is enabled? >> It's not. Don't be confused by the fact that -msse4.2 does not >> automatically turn on -mcrc32. Everything that is available when using >> -mcrc32 is also available when using -msse4.2. >> > thanks. >> Ian >> > cheers. -- Best Regards, xunxun