Generated assembler output doesn't store / restore registers

[Stefan Staiger]

GCC version: G++ v 3.1
Platform:         Linux (kernel 2.4.0 - 4GB, SuSE 7.1 distro) on a
    Intel Pentium 3 at 500 MHz
Problem in:     generated assembler output
Description:    generated function modifies eax and edx, but doesn't
    store/restore the original contents before returning to the caller


Hello GCC hackers,

I have the following problem with G++:
In the assembler output which the compiler generated for
even simple code files, it uses the registers eax and edx,
but doesn't store and restore them in the function. Thus,
the contents of those registers are destroyed which results in
mysterious program behaviour.

In the attached archive, I included the simplest example where
the problem occured (File Test.cpp), along with the makefile containing
the command line to invoke g++ and the assembler output Test.s
which g++ created for me.
As expected, g++ outputs one function. But in this function,
the register eax is modified (e.g. in line 16 "movzbl .LC0, %eax") and
since the function "Test" doesn't return anything, it should
store and restore this register. The same goes with the register
edx which is modified in line 22 by the instruction "movsbl %al, %edx".

I found out that when you use -O2 instead of -O3 as argument
for g++, it doesn't use the register edx (which indeed isn't needed,
so why does it even occur in the better optimized code ?). But,
in all of the optimization levels O0 - O3, the register eax is modified
and not restored. Since the called function must store / restore
the registers it modifies, I can't see the reason for this behaviour
in the g++-generated assembler code (The function Test is declared void,
so eax isn't "free" because it will contain the return value).

So is this a real bug or is there any rule that says that the caller
should know that some registers could be modified in this function ?
The problem originally occured in a more complex project, the files
attached are the simplest example I could create where it also occurs.

Good luck
Stefan Staiger

-------------- next part --------------
A non-text attachment was scrubbed...
Name: bug.tar.bz2
Type: application/x-bzip2
Size: 709 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-bugs/attachments/20020810/ece6898e/attachment.bz2>