這個是今天在微信群里討論的一個問題，先看圖片

點擊查看大圖

代碼流程大概是這個樣子的

點擊查看大圖

查看 length 和 space1 的值，明顯看到 length 小于 space1 的值，即使是這樣小白都能搞懂流程的情況下，代碼還是跑到else里面區(qū)執(zhí)行

調試查看數(shù)據(jù)

然后我們就在群里討論，有的大神說這個是內存越界，也有大神說可能是人品有問題，也有大神說這個是因為寫代碼前沒有選好一個良辰吉日，反正大家想法都非常多，也非常古怪，這可能就是討論群存在的一個原因了。

經(jīng)過不斷的驗證，發(fā)現(xiàn)這個問題是因為編譯器優(yōu)化的問題。

如果在設置里面把優(yōu)化選項去掉代碼就執(zhí)行正確

編譯器對代碼優(yōu)化

當然還有一個問題，就是如果我想開啟優(yōu)化，畢竟代碼太大占用的存儲空間是很大的，如果能節(jié)省點空間是最好的了。所以就出現(xiàn)了一種，只針對某些代碼不優(yōu)化的設置

像這樣

我們使用GCC編譯的時候，也是有可能因為代碼優(yōu)化導致這樣的問題的，慶幸的是，GCC也有設置不進行優(yōu)化的開關。

#使用GCC編譯器設置選擇性不優(yōu)化某段代碼

#pragma?GCC?push_options
#pragma?GCC?optimize?("O0")
#pragma?GCC?pop_options

push 的意思是把當前的編譯優(yōu)化選項壓棧，然后再設置當前的優(yōu)化選項，之后再出棧，把之前壓棧的選項提取出來。

具體可以參考鏈接：

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.

#當然還有指定某個函數(shù)設置優(yōu)化等級

int?max(int?a,?int?b)?__attribute__((optimize("O0")));
{
?return?a?}

#使用volatile 關鍵字避免編譯器優(yōu)化

volatile 的作用是提醒CPU，如果遇到被volatile 修飾的變量，要從內存里面去取值，而不要偷懶，直接從緩存里面取值，我們一般是用在那些被中斷處理函數(shù)使用的那些變量。

如果有些代碼，你不希望CPU偷懶，那你就可以加上volatile ，讓CPU從內存取數(shù)據(jù)。

CSDN上有這樣一個例子

https://blog.csdn.net/qq_28637193/article/details/88988951今天碰到一個gcc優(yōu)化相關的問題，為了讓一個頁變成臟頁（頁表中dirty位被置上），需要執(zhí)行下面這段代碼：

1?uint32_t?*page;
2?//?...
3?page[0]?=?page[0];
最后一行代碼很有可能被gcc優(yōu)化掉，因為這段代碼看起來沒有任何實際的作用。那么如何防止gcc對這段代碼做優(yōu)化呢？

設置gcc編譯時優(yōu)化級別為-O0肯定是不合適的，這樣對程序性能影響會比較大。stackoverflow上的Dietrich Epp給出了一個強制類型轉換的方案：

((unsigned?char?volatile?*)page)[0]?=?page[0];
通過volatile關鍵字禁止gcc的優(yōu)化