I am using the Code Sourcery G++ Lite gcc compiler with the optimization flag set to optimize size (Os).  Unfortunately this made the application unable to read or write to flash using EEPROM emulation.  I tried to optimize with only a level one without success.  This narrows down the flags to the list below:

          -fauto-inc-dec 
          -fcprop-registers 
          -fdce 
          -fdefer-pop 
          -fdelayed-branch 
          -fdse 
          -fguess-branch-probability 
          -fif-conversion2 
          -fif-conversion 
          -fipa-pure-const 
          -fipa-reference 
          -fmerge-constants
          -fsplit-wide-types 
          -ftree-builtin-call-dce 
          -ftree-ccp 
          -ftree-ch 
          -ftree-copyrename 
          -ftree-dce 
          -ftree-dominator-opts 
          -ftree-dse 
          -ftree-forwprop 
          -ftree-fre 
          -ftree-phiprop 
          -ftree-sra 
          -ftree-pta 
          -ftree-ter 
          -funit-at-a-time

Could one or more of these optimization flags cause EEPROM emulation to fail?

Well you could try adding in the optimisation flags one at a time until you start to get the problem again, but generally the route cause of this type of problem is something in the code being compiled, be it a volatile qualifier that is mising or something similar.  Likewise it could be something not quite right in the compiler, but I would go through the code with a fine tooth comb first.  These things can often be quite subtle. Regards.

Yes it is a problem with the loop counter after optimization.  I have setup a loop that counts the number of seconds.  Once that counter reaches a certain size data is stored into EEPROM and the value resets.   EEPROM works after the loop is diabled.  Unfortunately declaring a variable volatile only means that the value of the variable is retrieved from SRAM instead of directly accessing it from the registers by the MCU.  Does anyone have solved this problem before? Another thing that puzzles me is that after I get rid of a variable I do not use anymore in the header file STM32fx_it.c (the STM-32 peripheral library’s interrupt handler source file) with the optmization flag set to Os, the controller throws a Hard Fault Exception near the very beginning.  Of course Make Clean was the first thing I did.  I searched (and grepped) for any occurrances where the variable might be used without luck.  The problem is gone when I declare the variable again.  What is weird is that I do not even have to give the variable the same as the one I removed!  It seems that as long there is A variable the firmware is happy.  (All other variables are extern in the file).  Has anyone have encountered something similar before?