register variable is clobbered by passing parameter to a function

[Wolfgang Kuehn]

I know, what I do. This code snippet is the extract to see without any
overhead what happens with the compiled result.
In my original application the changing of the global variable to register
saves about 20% of program memory and I need this extra space for further
functionality.
And the code does what it shall (in register-version too). GCC compiles
exactly what it shall.
But only in the case of passing parameters to a function he "forget" that
the register is occupied by the variable.
For passing parameters he starts with r24 and goes down straight to the
lower registers (up to r8).
If there are still more parameters for passing, then he uses the stack.
Thats all ok, but:
if I use a local register variable, there is no warning, not even I use a
clobbered register (r18 and higher).
if I use a global register variable, there is a warning in case of clobbered
register, what is ok.
But no warning in case of non-clobbered registers.
The register keyword is not obligatory for the compiler, he can use a
register for the variable or not. But when he uses it,
then he shall not use it for other things (like passing) , or at least save
it. Or at least give a warning.
So I can not be shure, what result is compiled, is it reliable or not.
This behaviour says in conclusion, that you never has to use the register
keyword, because the compiler makes what he want. The harvard architecture
of the AVR-processor with his amount of registers is predestinated to make
use of registers.
So I believe, it is a bug.
The gcc-docu says:
a.. Global register variables reserve registers throughout the program. This
may be useful in programs such as programming language interpreters which
have a couple of global variables that are accessed very often.
a..  Choose a register which is normally saved and restored by function
calls on your machine, so that library routines will not clobber it.
a.. Call-saved registers (r2-r17, r28-r29): Calling C subroutines leaves
them unchanged.

I discussed these problems before in the avr-gcc-forum and they were not
shure is it a compiler bug or a document bug. They advised me to get the
help of the mailing list: "There the real gcc gurus can probably answer your
question".

best regards
wolfgang