BX LR generation

> Well, another good reason for a compiler to omit a return from a function is the case when
> the function doesn't ever return, like a typical main().

Or in case the compiler applied tail-call optimization.

int var;

int bar()
{
   return var;
}

int foo()
{
   return bar();
}

(assuming the compiler doesn't inline this silly example)

--
Marcus
http://www.doulos.com/arm/

"Well, another good reason for a compiler to omit a return from a function is the case when the function doesn't ever return, like a typical main()."

A valid point, I'd forgotten that one.

Mike,

I have an enormous amount of work now. I will try to post a code snippet in the very near future.

The only instance I know of where the compiler does not generate a return from a function is when it is an __asm function, so you add it to the function yourself.

Well, another good reason for a compiler to omit a return from a function is the case when the function doesn't ever return, like a typical main().
So yes, some actual source code would be in order.

if I place the function that is called from startup code in a separate C module - a "BX LR" is generated!

And you're sure that's not just because the compiler inlined that function, and thus there was no need to return from it?

A little actual source and actual assembler output of both that function and its caller would go a long way towards clarifying this puzzle...

Mid-October? First it was mid-September, then beginning October, and now this...

"YES!"

OMG. Sounds nasty!

I reported a problem with compiler produced code a few weeks ago (-O3 was creating faulty inline code) and was told that there should be a compiler update around mid-October.

Are you saying that your one C function just falls through to the next?

YES!

I will try to send this program to Keil so they can see it. This cause me SO MUCH heard ache today (when combined with other changes...).

"...the compiler does not generate a "BX LR" instruction at its end."

The only instance I know of where the compiler does not generate a return from a function is when it is an __asm function, so you add it to the function yourself.

If you look at the assembler produced for the C module, you surely see the returns in other functions?

Are you saying that your one C function just falls through to the next?

I think this is a tool chain but - if I place the function that is called from startup code in a separate C module - a "BX LR" is generated!