来看看编译器的聪明之处！

如下图：黑色下划线是单片机STM32软件复位语句，
再往下语句就不再编译了。
如图中FLASH_Unlock()函数就不运行了。
难道编译器看出来这是复位语句了，所以剩余的语句就没必要编译了。
太聪明了吧，有些害怕。

附NVIC_SystemReset()函数原型！
static __INLINE void NVIC_SystemReset(void)
{
  SCB->AIRCR  = ((0x5FA << SCB_AIRCR_VECTKEY_Pos)      |
                 (SCB->AIRCR & SCB_AIRCR_PRIGROUP_Msk) |
                 SCB_AIRCR_SYSRESETREQ_Msk);                   /* Keep priority group unchanged */
  __DSB();                                                     /* Ensure completion of memory access */              
  while(1);                                                    /* wait until reset */
}

再上图
屏蔽掉软件复位语句后，下面的语句可以被编译。

                                 晕倒，都复位了还能运行到FLASH_Unlock()吗？不是没编译，而是根本没机会运行到那

谢谢楼上回复，
请注意两幅图片的不同：
1楼图中FLASH_Unlock();左侧没有变灰，说明该语句没有编译。
2楼图中FLASH_Unlock();左侧变灰，说明该语句编译了。

现在我们探讨编译器的问题，不谈运行，运行当然运行不过去的。
好奇的是，编译器不编译FLASH_Unlock，遇到reset，往下就不编译了。
难道编译器是知道这是复位？

是因为while(1); 吧

                                 楼上正解。有了while(1)，后面就没有机会运行到了。有些编译器还会给出警告，告知这个程序有那些地方是不可能运行到的。

实验验证正如楼上2位所说。
再次感谢2位！

                                 哈哈，差点儿聪明反被聪明误，

                                 哈哈，聪明反被聪明误  

对，既然后面的程序运行不了，编译器当然不会把“垃圾代码”编译，浪费ROM

                                 这个可能涉及到代码覆盖率问题，编译器分析后边的代码执行 覆盖率为0，优化级别高时会去掉的。

你可以试着骗骗编译器。
如下：
volatile u32 DaPianZi_flag;
DaPianZi_flag=1;
while(DaPianZi_flag);
要是还骗不到，就可以去跟编译器厂商拿bug举报奖金了。

这是因为 NVIC_SystemReset 是static inline的，
在编译器看得到的范围内。

如果NVIC_SystemReset是external的，又是另一个光景了，即便有while(1)