[fpc-devel] An optimizer bug?

Jonas Maebe jonas.maebe at elis.ugent.be
Fri Dec 28 16:24:31 CET 2007

On 28 Dec 2007, at 15:16, Sergei Gorelkin wrote:

> I had isolated the issue, it is maybechangetemp() in ncgld.pas. If I  
> modify this function to always return false, the issue is gone.  
> Actually the failure is caused by incomplete deallocation of the  
> AnsiString temp variable - its initialization and finalization code  
> is not deleted.
> ...But what the hell is happening? First, at pass1 compiler does a  
> whole load of checks, decides that the assignment of function result  
> cannot be optimized, and allocates an intermediate temp. Then, at  
> pass2 (and with -O2 specified), it optimizes this assignment and  
> tries to delete the temp, based solely on the fact that the right  
> side of assignment is LOC_REFERENCE. All escape analysis from pass1  
> is void then?

maybechangetemp() predates the existence of the escape analysis. It's  
orthogonal to the function result optimization. It's simply that if  
you have


then you can, under certain circumstances (and there's probably an  
incompatibility between the checks here and your changes -- keep in  
mind that checks/optimizations are often written with what the  
compiler can generate in mind, and not based on all possible code  
sequences that exist; that's also why the assembler optimizer is not  
run on user-written assembler), actually do something like


(i.e., any further reference to memloc1 from then on will actually use  
memloc2 instead, regardless of whether memloc2 comes from a function  
result or from something else).

> How should this be fixed?

I don't know by heart, and I'll soon leave on holidays until January,  
1st, so I won't have time to check during the coming days (but it's  
possible that.


More information about the fpc-devel mailing list