[fpc-devel] One more issue with string function results (hopefully, the last)
Peter Vreman
peter at freepascal.org
Tue Jan 22 19:45:23 CET 2008
> Hello,
>
> Ran into it while compiling Lazarus. It appears that, while many
> sophisticated checks are done in tcallnode.maybe_create_funcret_node,
> the obvious case when function result destination is one of the
> function's arguments, is not checked. To be honest, I noticed that
> earlier for the case of s := Copy(s, ...), but was thiniking that there
> is some compiler magic around Copy(). Delphi also appears to be smart
> enough to omit temps in case of s := copy(s,...).
> Anyway, since copy() assigns its result once before exiting, it works
> fine. Things go wrong when the function is tries to access its argument
> after modifying the result, like in the attached example.
This issue is caused by your own patch to change the ansistring code to use pass the result by
reference.
Original code (using current 2.2.1) was:
# [21] s := foo(s); // This one failes
movl -4(%ebp),%eax
call P$PROGRAM_FOO$ANSISTRING$$ANSISTRING
movl %eax,%ebx
leal -4(%ebp),%eax
call FPC_ANSISTR_DECR_REF
movl %ebx,-4(%ebp)
The new code since r9718 is:
# [21] s := foo(s); // This one failes
leal -4(%ebp),%edx
movl -4(%ebp),%eax
call P$PROGRAM_FOO$ANSISTRING$$ANSISTRING
Here you can see that the result is at the same location as the parameter. In the original code
the value is only assigned to the original location after the call.
The quick-solution is simple: revert r9718 until it works.
Peter
More information about the fpc-devel
mailing list