Make sure that your empty-loop counter is declared volatile, otherwise
the compiler may optimise it out. It fixed it here:
http://en.mikrocontroller.net/topic/83014#146546, here:
http://en.mikrocontroller.net/topic/106276#239418 and
here:http://en.mikrocontroller.net/topic/60811#58628

That said, using a loop to implement delays is problematic for this and
many other reasons, all ARM based micro-controllers include timer
hardware which would be a better way to implement timing functions (and
probably consume less power).

Clifford

Vicente wrote:
> In short, the problem I have is, after having all instaled, configured,
> and running, I only can 'blink' a output port if I compile the source
> file with the -O1, -O2, -O3 or -Os option in the arm-elf-gcc. If I
> compile with the option -O0 (or without entering any -O parameter), the
> program seems not to run. And the port doesn't blink.

It's difficult to help without knowing the target and code. "Doesn't
blink" could mean anything. Maybe some delay-loops in unoptimized builds
are that slow that you simple have to wait for "blinking". Do you have
some debugging soft- and hardware? A simple Wiggler-type JTAG-hardware,
OpenOCD and gdb should do.

> Thank you very very much. I don't know what to do. I want to compile
> with no optimization option because I want to use some active wait loops
> (you know, e.g. for(i=0; i<100000; i++); )

As Clifford already pointed out this is not a good approach to implement
delays for "real-world" applications.  But yes, such delays-loops should
work with -O0. But I have never tested this myself without declaring the
counter-variable as volatile (I usualy use -Os or -O2 for my free and
commercial projects). So if you just need the delay-loop use volatile
unsigned long i to declare the counter and keep the optimization
enabled. While -Ox with x>0 and the volatile should get you going the
"doesn't blink"-problem with -O0 might have another reason.

Martin Thomas