這個是優化今天在微信群里討論的一個問題，先看圖片
代碼流程大概是葩問這個樣子的
查看 length和 space1的值，明顯看到 length小于 space1的代碼導致的奇值，即使是優化這樣小白都能搞懂流程的情況下，代碼還是葩問跑到else里面區執行
然后 我們就在群里討論，有的大神說這個是內存越界，也有大神說可能是人品有問題，也有大神說這個是因為寫代碼前沒有選好一個良辰吉日，反正大家想法都非常多，也非常古怪，這可能就是討論群存在的一個原因了。
經過不斷的驗證，發現這個問題是因為編譯器優化的問題。
如果在設置里面把優化選項去掉代碼就執行正確
當然還有一個問題，就是如果我想開啟優化，畢竟代碼太大占用的存儲空間是很大的，如果能節省點空間是最好的了。所以就出現了一種，只針對某些代碼不優化的設置
像這樣
我們使用GCC編譯的時候，也是有可能因為代碼優化導致這樣的問題的，慶幸的是，GCC也有設置不進行優化的開關。
#使用GCC編譯器設置選擇性不優化某段代碼
#pragma?GCC?push_options
#pragma?GCC?optimize?("O0")
#pragma?GCC?pop_options
push 的意思是把當前的編譯優化選項壓棧，然后再設置當前的優化選項，之后再出棧，把之前壓棧的選項提取出來。
具體可以參考鏈接：
https://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Function-Specific-Option-Pragmas.html
鏈接里面還介紹了一些其他的用法，原文如下
5.52.12?Function?Specific?Option?Pragmas
#pragma?GCC?target?("string"...)
This?pragma?allows?you?to?set?target?specific?options?for?functions?defined?later?in?the?source?file.?One?or?more?strings?can?be?specified.?Each?function?that?is?defined?after?this?point?will?be?as?if?attribute((target("STRING")))?was?specified?for?that?function.?The?parenthesis?around?the?options?is?optional.?See?Function?Attributes,?for?more?information?about?the?target?attribute?and?the?attribute?syntax.
The?`#pragma?GCC?target'?pragma?is?not?implemented?in?GCC?versions?earlier?than?4.4,?and?is?currently?only?implemented?for?the?386?and?x86_64?backends.
#pragma?GCC?optimize?("string"...)
This?pragma?allows?you?to?set?global?optimization?options?for?functions?defined?later?in?the?source?file.?One?or?more?strings?can?be?specified.?Each?function?that?is?defined?after?this?point?will?be?as?if?attribute((optimize("STRING")))?was?specified?for?that?function.?The?parenthesis?around?the?options?is?optional.?See?Function?Attributes,?for?more?information?about?the?optimize?attribute?and?the?attribute?syntax.
The?`#pragma?GCC?optimize'?pragma?is?not?implemented?in?GCC?versions?earlier?than?4.4.
#pragma?GCC?push_options
#pragma?GCC?pop_options
These?pragmas?maintain?a?stack?of?the?current?target?and?optimization?options.?It?is?intended?for?include?files?where?you?temporarily?want?to?switch?to?using?a?different?`#pragma?GCC?target'?or?`#pragma?GCC?optimize'?and?then?to?pop?back?to?the?previous?options.
The?`#pragma?GCC?push_options'?and?`#pragma?GCC?pop_options'?pragmas?are?not?implemented?in?GCC?versions?earlier?than?4.4.
#pragma?GCC?reset_options
This?pragma?clears?the?current?#pragma?GCC?target?and?#pragma?GCC?optimize?to?use?the?default?switches?as?specified?on?the?command?line.
The?`#pragma?GCC?reset_options'?pragma?is?not?implemented?in?GCC?versions?earlier?than?4.4.
#當然還有指定某個函數設置優化等級
int?max(int?a,?int?b)?__attribute__((optimize("O0")));
{
?return?a?}
#使用volatile 關鍵字避免編譯器優化
volatile 的作用是提醒CPU，如果遇到被volatile 修飾的變量，要從內存里面去取值，而不要偷懶，直接從緩存里面取值，我們一般是用在那些被中斷處理函數使用的那些變量。
如果有些代碼，你不希望CPU偷懶，那你就可以加上volatile ，讓CPU從內存取數據。
CSDN上有這樣一個例子
https://blog.csdn.net/qq_28637193/article/details/88988951今天碰到一個gcc優化相關的問題，為了讓一個頁變成臟頁（頁表中dirty位被置上），需要執行下面這段代碼：
1?uint32_t?*page;
2?//?...
3?page[0]?=?page[0];
最后一行代碼很有可能被gcc優化掉，因為這段代碼看起來沒有任何實際的作用。那么如何防止gcc對這段代碼做優化呢？
設置gcc編譯時優化級別為-O0肯定是不合適的，這樣對程序性能影響會比較大。stackoverflow上的Dietrich Epp給出了一個強制類型轉換的方案：
((unsigned?char?volatile?*)page)[0]?=?page[0];
通過volatile關鍵字禁止gcc的優化
#總結、什么情況會導致這樣的問題？
1、堆棧溢出應該是一個原因，之前我有遇到的情況是棧空間設置太小，然后溢出到堆空間導致問題。
2、使用某個函數導致溢出，我們使用的函數，比如，內存拷貝函數，如果長度設置不對，也會導致影響到其他的代碼。
3、還有就是上面說的編譯器優化導致的問題。
原創不易，歡迎轉發、留言、點贊、分享給你的朋友，感謝您的支持！
長按識別二維碼關注獲取更多內容
免責聲明：本文內容由21ic獲得授權后發布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯系我們，謝謝！
