編譯o2到底好不好

Ⅰ 在G++中，優化級別-O3是否危險

在gcc的早期（2.8等）和egcs時代，redhat 2.96 -O3有時是相當多的錯誤。但這是十年前的事了，-O3與其他級別的優化（在兒童車中）沒有太大不同。
但是，由於確實更嚴格地依賴語言的規則，特別是一些極端情況，它確實傾向於揭示人們依賴未定義行為的情況。
作為個人說明，我使用-O3在金融領域運行生產軟體已有很多年了，並且還沒有遇到過如果我使用-O2就不會出現的錯誤。
根據大眾需求，這里有一個補充：
-O3尤其是諸如-funroll-loops之類的其他標志（未由-O3啟用）有時會導致生成更多機器代碼。在某些情況下（例如，在具有非常小的L1指令高速緩存的CPU上），這可能會導致速度變慢，這是因為某些內部循環的所有代碼現在不再適合L1I。通常，gcc會盡力避免不生成太多代碼，但是由於它通常會優化一般情況，因此可能會發生這種情況。-O3中通常不包括特別容易發生這種情況的選項（例如循環展開），並在手冊頁中進行了相應標記。因此，通常最好使用-O3來生成快速代碼，並且僅在適當的時候（例如，當探查器指示L1I未命中時）回退到-O2或-Os（嘗試對代碼大小進行優化）。
如果想將優化工作發揮到極致，則可以通過–param調整與某些優化相關的成本。另外請注意，gcc現在可以將屬性放在僅控制這些功能的優化設置的功能上，因此，當您發現一個功能中的-O3有問題（或想嘗試該功能的特殊標志）時，您無需使用O2編譯整個文件甚至整個項目。
在使用-Ofast時，似乎必須小心，它指出：
-Ofast啟用所有-O3優化。它還啟用了並非對所有符合標準的程序都有效的優化。
這使我得出結論，-O3旨在完全符合標准。

Ⅱ 如何設置NDK的編譯選項

1. 概述

首先回顧一下 Android NDK 開發中，Android.mk 和Application.mk 各自的職責。

Android.mk，負責配置如下內容：

（1） 模塊名（LOCAL_MODULE）

（2） 需要編譯的源文件（LOCAL_SRC_FILES）

（3） 依賴的第三方庫（LOCAL_STATIC_LIBRARIES，LOCAL_SHARED_LIBRARIES）

（4） 編譯/鏈接選項（LOCAL_LDLIBS、LOCAL_CFLAGS）

Application.mk，負責配置如下內容：

（1） 目標平台的ABI類型（默認值：armeabi）（APP_ABI）

（2） Toolchains（默認值：GCC 4.8）

（3） C++標准庫類型（默認值：system）（APP_STL）

（4） release/debug模式（默認值：release）

由此我們可以看到，本文所涉及的編譯選項在Android.mk和Application.mk中均有出現，下面我們將一個個詳細介紹。

2. APP_ABI

ABI全稱是：Application binary interface，即：應用程序二進制介面，它定義了一套規則，允許編譯好的二進制目標代碼在所有兼容該ABI的操作系統和硬體平台中無需改動就能運行。（具體的定義請參考網路或者維基網路）

由上述定義可以判斷，ABI定義了規則，而具體的實現則是由編譯器、CPU、操作系統共同來完成的。不同的CPU晶元（如：ARM、Intel x86、MIPS）支持不同的ABI架構，常見的ABI類型包括：armeabi，armeabi-v7a，x86，x86_64，mips，mips64，arm64-v8a等。

這就是為什麼我們編譯出來的可以運行於Windows的二進製程序不能運行於Mac OS/linux/Android平台了，因為CPU晶元和操作系統均不相同，支持的ABI類型也不一樣，因此無法識別對方的二進製程序。

而我們所說的「交叉編譯」的核心原理也跟這些密切相關，交叉編譯，就是使用交叉編譯工具，在一個平台上編譯生成另一個平台上的二進制可執行程序，為什麼可以做到？因為交叉編譯工具實現了另一個平台所定義的ABI規則。我們在Windows/Linux平台使用Android NDK交叉編譯工具來編譯出Android平台的庫也是這個道理。

這里給出最新 Android NDK 所支持的ABI類型及區別：

下面是我總結的一些常用的CFLAGS編譯選項：

（1）通用的編譯選項

-O2 編譯優化選項，一般選擇O2，兼顧了優化程度與目標大小

-Wall 打開所有編譯過程中的Warning

-fPIC 編譯位置無關的代碼，一般用於編譯動態庫

-shared 編譯動態庫

-fopenmp 打開多核並行計算，

-Idir 配置頭文件搜索路徑，如果有多個-I選項，則路徑的搜索先後順序是從左到右的，即在前面的路徑會被選搜索

-nostdinc 該選項指示不要標准路徑下的搜索頭文件，而只搜索-I選項指定的路徑和當前路徑。

--sysroot=dir 用dir作為頭文件和庫文件的邏輯根目錄，例如，正常情況下，如果編譯器在/usr/include搜索頭文件，在/usr/lib下搜索庫文件，它將用dir/usr/include和dir/usr/lib替代原來的相應路徑。

-llibrary 查找名為library的庫進行鏈接

-Ldir 增加-l選項指定的庫文件的搜索路徑，即編譯器會到dir路徑下搜索-l指定的庫文件。

-nostdlib 該選項指示鏈接的時候不要使用標准路徑下的庫文件

（2） ARM平台相關的編譯選項

-marm -mthumb 二選一，指定編譯thumb指令集還是arm指令集

-march=name 指定特定的ARM架構，常用的包括：-march=armv6， -march=armv7-a

-mfpu=name 給出目標平台的浮點運算處理器類型，常用的包括：-mfpu=neon，-mfpu=vfpv3-d16

-mfloat-abi=name 給出目標平台的浮點預算ABI，支持的參數包括：「soft」, 「softfp」 and 「hard」

Ⅲ 什麼叫 -O2編譯

【-O2編譯】編譯器提供-O選項，供程序優化使用。其中：
1、-O0表示沒有優化；
2、-O1為預設值，提供基礎級別的優化；
3、-O2 提供更加高級的代碼優化,會佔用更長的編譯時間；
4、-O3 提供最高級的代碼優化。
【編譯器】就是將「一種語言（通常為高級語言）」翻譯為「另一種語言（通常為低級語言）」的程序。一個現代編譯器的主要工作流程：源代碼 (source code) → 預處理器 (preprocessor) → 編譯器 (compiler) → 目標代碼 (object code) → 鏈接器(Linker) → 可執行程序 (executables)
高級計算機語言便於人編寫，閱讀交流，維護。機器語言是計算機能直接解讀、運行的。編譯器將匯編或高級計算機語言源程序（Source program）作為輸入，翻譯成目標語言（Target language）機器代碼的等價程序。源代碼一般為高級語言 (High-level language)， 如Pascal、C、C++、java、漢語編程等或匯編語言，而目標則是機器語言的目標代碼（Object code），有時也稱作機器代碼（Machine code）。

Ⅳ 請問noip 的「編譯命令(不包含任何優化開關）」是什麼意思，望解答

意思就是
Pascal:fpc %s.pas
G++:g++ %s.cpp -o %s.exe
GCC:gcc %s.c -o %s.exe
無視Pascal文件里的開關

有的人編譯時喜歡開-o -o2 -o3，速度快點，但是noip不允許這個
而且-o2可以影響程序行為

Ⅳ linux下如何查看一個二進制文件是使用-O0優化還是-O2優化

gcc默認提供了5級優化選項：
-O/-O0:無優化(默認)
-O1:使用能減少目標文件大小以及執行時間並且不會使編譯時間明顯增加的優化。該模式在編譯大型程序的時候會花費更多的時間和內存。在-O1下：編譯會嘗試減少代碼體積和代碼運行時間，但是並不執行會花費大量時間的優化操作。
-O2: 包含-O1的優化並增加了不需要在目標文件大小和執行速度上進行折衷的優化。GCC執行幾乎所有支持的操作但不包括空間和速度之間權衡的優化，編譯器不執行循環展開以及函數內聯。這是推薦的優化等級，除非你有特殊的需求。-O2會比-O1啟用多一些標記。與-O1比較該優化-O2將會花費更多的編譯時間當然也會生成性能更好的代碼。
-Os:專門優化目標文件大小,執行所有的不增加目標文件大小的-O2優化選項。同時-Os還會執行更加優化程序空間的選項。這對於磁碟空間極其緊張或者CPU緩存較小的機器非常有用。但也可能產生些許問題，因此軟體樹中的大部分ebuild都過濾掉這個等級的優化。使用-Os是不推薦的。
-O3: 打開所有-O2的優化選項並且增加 -finline-functions, -funswitch-loops,-fpredictive-commoning, -fgcse-after-reload and -ftree-vectorize優化選項。這是最高最危險的優化等級。用這個選項會延長編譯代碼的時間，並且在使用gcc4.x的系統里不應全局啟用。自從3.x版本以來gcc的行為已經有了極大地改變。在3.x，-O3生成的代碼也只是比-O2快一點點而已，而gcc4.x中還未必更快。用-O3來編譯所有的軟體包將產生更大體積更耗內存的二進制文件，大大增加編譯失敗的機會或不可預知的程序行為（包括錯誤）。這樣做將得不償失，記住過猶不及。在gcc 4.x.中使用-O3是不推薦的。
————————————————
版權聲明：本文為CSDN博主「rongming_lu」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/LU_ZHAO/java/article/details/104516291

Ⅵ Linux下gcc編譯介紹

Linux系統下的Gcc（GNU C Compiler）是GNU推出的功能強大、性能優越的多平台編譯器，是GNU的代表作品之一。gcc是可以在多種硬體平台上編譯出可執行程序的超級編譯器，其執行效率與一般的編譯器相比平均效率要高20%~30%。
Gcc編譯器能將C、C++語言源程序、匯程式化序和目標程序編譯、連接成可執行文件，如果沒有給出可執行文件的名字，gcc將生成一個名為a.out的文件。在Linux系統中，可執行文件沒有統一的後綴，系統從文件的屬性來區分可執行文件和不可執行文件。而gcc則通過後綴來區別輸入文件的類別，下面我們來介紹gcc所遵循的部分約定規則。
.c為後綴的文件，C語言源代碼文件；
.a為後綴的文件，是由目標文件構成的檔案庫文件；
.C，.cc或.cxx 為後綴的文件，是C++源代碼文件；
.h為後綴的文件，是程序所包含的頭文件；
.i 為後綴的文件，是已經預處理過的C源代碼文件；
.ii為後綴的文件，是已經預處理過的C++源代碼文件；
.m為後綴的文件，是Objective-C源代碼文件；
.o為後綴的文件，是編譯後的目標文件；
.s為後綴的文件，是匯編語言源代碼文件；
.S為後綴的文件，是經過預編譯的匯編語言源代碼文件。
Gcc的執行過程
雖然我們稱Gcc是C語言的編譯器，但使用gcc由C語言源代碼文件生成可執行文件的過程不僅僅是編譯的過程，而是要經歷四個相互關聯的步驟∶預處理(也稱預編譯，Preprocessing)、編譯(Compilation)、匯編(Assembly)和連接(Linking)。
命令gcc首先調用cpp進行預處理，在預處理過程中，對源代碼文件中的文件包含(include)、預編譯語句(如宏定義define等)進行分析。接著調用cc1進行編譯，這個階段根據輸入文件生成以.o為後綴的目標文件。匯編過程是針對匯編語言的步驟，調用as進行工作，一般來講，.S為後綴的匯編語言源代碼文件和匯編、.s為後綴的匯編語言文件經過預編譯和匯編之後都生成以.o為後綴的目標文件。當所有的目標文件都生成之後，gcc就調用ld來完成最後的關鍵性工作，這個階段就是連接。在連接階段，所有的目標文件被安排在可執行程序中的恰當的位置，同時，該程序所調用到的庫函數也從各自所在的檔案庫中連到合適的地方。

Gcc的基本用法和選項
在使用Gcc編譯器的時候，我們必須給出一系列必要的調用參數和文件名稱。Gcc編譯器的調用參數大約有100多個，其中多數參數我們可能根本就用不到，這里只介紹其中最基本、最常用的參數。
Gcc最基本的用法是∶gcc [options] [filenames]
其中options就是編譯器所需要的參數，filenames給出相關的文件名稱。
-c，只編譯，不連接成為可執行文件，編譯器只是由輸入的.c等源代碼文件生成.o為後綴的目標文件，通常用於編譯不包含主程序的子程序文件。
-o output_filename，確定輸出文件的名稱為output_filename，同時這個名稱不能和源文件同名。如果不給出這個選項，gcc就給出預設的可執行文件a.out。
-g，產生符號調試工具(GNU的gdb)所必要的符號資訊，要想對源代碼進行調試，我們就必須加入這個選項。
-O，對程序進行優化編譯、連接，採用這個選項，整個源代碼會在編譯、連接過程中進行優化處理，這樣產生的可執行文件的執行效率可以提高，但是，編譯、連接的速度就相應地要慢一些。
-O2，比-O更好的優化編譯、連接，當然整個編譯、連接過程會更慢。
-Idirname，將dirname所指出的目錄加入到程序頭文件目錄列表中，是在預編譯過程中使用的參數。C程序中的頭文件包含兩種情況∶
A)#include
B)#include 「myinc.h」
其中，A類使用尖括弧(< >)，B類使用雙引號(「 」)。對於A類，預處理程序cpp在系統預設包含文件目錄(如/usr/include)中搜尋相應的文件，而對於B類，cpp在當前目錄中搜尋頭文件，這個選項的作用是告訴cpp，如果在當前目錄中沒有找到需要的文件，就到指定的dirname目錄中去尋找。在程序設計中，如果我們需要的這種包含文件分別分布在不同的目錄中，就需要逐個使用-I選項給出搜索路徑。
-Ldirname，將dirname所指出的目錄加入到程序函數檔案庫文件的目錄列表中，是在連接過程中使用的參數。在預設狀態下，連接程序ld在系統的預設路徑中(如/usr/lib)尋找所需要的檔案庫文件，這個選項告訴連接程序，首先到-L指定的目錄中去尋找，然後到系統預設路徑中尋找，如果函數庫存放在多個目錄下，就需要依次使用這個選項，給出相應的存放目錄。
-lname，在連接時，裝載名字為「libname.a」的函數庫，該函數庫位於系統預設的目錄或者由-L選項確定的目錄下。例如，-lm表示連接名為「libm.a」的數學函數庫。
上面我們簡要介紹了gcc編譯器最常用的功能和主要參數選項，更為詳盡的資料可以參看Linux系統的聯機幫助。
假定我們有一個程序名為test.c的C語言源代碼文件，要生成一個可執行文件，最簡單的辦法就是∶
gcc test.c
這時，預編譯、編譯連接一次完成，生成一個系統預設的名為a.out的可執行文件，對於稍為復雜的情況，比如有多個源代碼文件、需要連接檔案庫或者有其他比較特別的要求，就要給定適當的調用選項參數。再看一個簡單的例子。
整個源代碼程序由兩個文件testmain.c 和testsub.c組成，程序中使用了系統提供的數學庫，同時希望給出的可執行文件為test，這時的編譯命令可以是∶
gcc testmain.c testsub.c □lm □o test
其中，-lm表示連接系統的數學庫libm.a。

Gcc的錯誤類型及對策
Gcc編譯器如果發現源程序中有錯誤，就無法繼續進行，也無法生成最終的可執行文件。為了便於修改，gcc給出錯誤資訊，我們必須對這些錯誤資訊逐個進行分析、處理，並修改相應的語言，才能保證源代碼的正確編譯連接。gcc給出的錯誤資訊一般可以分為四大類，下面我們分別討論其產生的原因和對策。

第一類∶C語法錯誤
錯誤資訊∶文件source.c中第n行有語法錯誤(syntex errror)。這種類型的錯誤，一般都是C語言的語法錯誤，應該仔細檢查源代碼文件中第n行及該行之前的程序，有時也需要對該文件所包含的頭文件進行檢查。有些情況下，一個很簡單的語法錯誤，gcc會給出一大堆錯誤，我們最主要的是要保持清醒的頭腦，不要被其嚇倒，必要的時候再參考一下C語言的基本教材。
第二類∶頭文件錯誤
錯誤資訊∶找不到頭文件head.h(Can not find include file head.h)。這類錯誤是源代碼文件中的包含頭文件有問題，可能的原因有頭文件名錯誤、指定的頭文件所在目錄名錯誤等，也可能是錯誤地使用了雙引號和尖括弧。

第三類∶檔案庫錯誤
錯誤資訊∶連接程序找不到所需的函數庫，例如∶
ld: -lm: No such file or directory
這類錯誤是與目標文件相連接的函數庫有錯誤，可能的原因是函數庫名錯誤、指定的函數庫所在目錄名稱錯誤等，檢查的方法是使用find命令在可能的目錄中尋找相應的函數庫名，確定檔案庫及目錄的名稱並修改程序中及編譯選項中的名稱。
第四類∶未定義符號
錯誤資訊∶有未定義的符號(Undefined symbol)。這類錯誤是在連接過程中出現的，可能有兩種原因∶一是使用者自己定義的函數或者全局變數所在源代碼文件，沒有被編譯、連接，或者乾脆還沒有定義，這需要使用者根據實際情況修改源程序，給出全局變數或者函數的定義體；二是未定義的符號是一個標準的庫函數，在源程序中使用了該庫函數，而連接過程中還沒有給定相應的函數庫的名稱，或者是該檔案庫的目錄名稱有問題，這時需要使用檔案庫維護命令ar檢查我們需要的庫函數到底位於哪一個函數庫中，確定之後，修改gcc連接選項中的-l和-L項。
排除編譯、連接過程中的錯誤，應該說這只是程序設計中最簡單、最基本的一個步驟，可以說只是開了個頭。這個過程中的錯誤，只是我們在使用C語言描述一個演算法中所產生的錯誤，是比較容易排除的。我們寫一個程序，到編譯、連接通過為止，應該說剛剛開始，程序在運行過程中所出現的問題，是演算法設計有問題，說得更玄點是對問題的認識和理解不夠，還需要更加深入地測試、調試和修改。一個程序，稍為復雜的程序，往往要經過多次的編譯、連接和測試、修改。下面我們學習的程序維護、調試工具和版本維護就是在程序調試、測試過程中使用的，用來解決調測階段所出現的問題。窗體頂端
窗體底端

Ⅶ O2優化掃盲

O2優化實際上是Optimize，2是優化等級。除了O2優化還有O3優化，這是更高等級的優化；還有Ofast、Os等等多種優化等級，對於有些演算法題，使用暴力演算法+O2優化是可以正常AC的；但是注意並不是所有O2優化都是正優化，有的會是負優化

[gcc官方關於O2優化的說明] ( https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html )

但是實際應用中STL編譯的時候，我們會開 優化，開完之後其實速度跟數組模擬的隊列差不多快
在演算法競賽中，比賽方一般不會開O2優化，這種情況下STL的棧隊列要比數組模擬的棧隊列慢一倍左右
O2優化的知識點還是非常重要的！！！