On Jan 17, 2009, at 3:02 PM, Dag Sverre Seljebotn wrote: > It is supposed to work, that's why generate_disposal_code and > free_temps are seperate calls. The former can be called multiple > times in generate_..._code, the latter must be called exactly once. > The temporary variable will be held on to until the end of the C > branch, which is optimized away by gcc. > > You'll find examples somewhere of this, but I can't remember where > at the moment.
Sure. I'm was just musing about it not meshing well with old vs. new temps, which is the real issue that needs attention. - Robert > Dag Sverre Seljebotn > -----Original Message----- > From: Robert Bradshaw <[email protected]> > Date: Saturday, Jan 17, 2009 11:37 pm > Subject: Re: [Cython] Temp allocation bug > To: [email protected]: [email protected] > > On Jan 17, 2009, at 2:20 PM, Dag Sverre Seljebotn wrote: >> >>> Robert wrote: >>> Is this going to be a general problem with any inside a >>> NewTempExprNode (plain) ExprNode? That could be bad. On that >>> note, is >>> there any reason that temp freeing is done as a separate step now >>> instead of as part of the disposal code? (Someone more familiar with >>> the new code probably has a trivial answer to this.) >> >>> Some code is generated like this: >> >>> /*allocate node*/ >> if (something) { >> block A >> /* deallocate node */ >> } else { >> block B >> /* deallocate node */ >> } >> >>> If temp releasing is tied up with disposal, the temp can be >> reallocated >> and reused in block B, leading to disaster. Also it would be released >> twice. Etc. >> >>> If the C control flow matched the node tree, this wouldn't be a >> problem, >> but it doesn't. >> >>> Pyrex didn't have this problem, but that meant that deallocation >>> (i.e. >> decrefs) is done later than necesarry. >> >> Ah, I see. >> >> Well, I'd rather deallocate too late than deallocate incorrectly. >> Does this mean that it's all or nothing with the NewTempExprNodes, or >> is a mix and match supposed to work? >> >> - Robert >> >> _______________________________________________ >> Cython-dev mailing list >> [email protected] >> http://codespeak.net/mailman/listinfo/cython-dev >> > > _______________________________________________ > Cython-dev mailing list > [email protected] > http://codespeak.net/mailman/listinfo/cython-dev _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
