Michael Matz wrote:
Unfortunately I had to add one other place where it checks nocode_wanted and that's in the ugly dealing with VT_CMP/VT_JMP values in vtop. See testcases in the above, and my comment included here for citing/discussing:+ Don't do this when nocode_wanted. vtop might come from + !nocode_wanted regions (see 88_codeopt.c) and transforming + it to a register without actually generating code is wrong + as their value might still be used for real. All values + we push under nocode_wanted will eventually be popped + again, so that the VT_CMP/VT_JMP value will be in vtop + when code is unsuppressed again. */ + if (vtop >= vstack && !nocode_wanted) { v = vtop->r & VT_VALMASK; if (v == VT_CMP || (v & ~1) == VT_JMP) gv(RC_INT);I hope I haven't broken anything that you've fixed with your three nocode_wanted patches ...
No, I guess it makes sense. Except there is the same clause in vswap() down below which we'll probably want to treat the same way. Also I'd share the assumption that nocode-branches must be neutral to vstack and it is up to the nocode-user to care about. The gsym() in vpop() is ok IMO, it will fixup a jump chain on vtop to the current "ind" pointer. That 'ind' doesn't change under 'nocode' does not matter. Btw, what's "pseudo leak" in a one-shot tool, in libtcc will write to memory that already has been free'd by the underlying "TAL" manager. Sorry if I didn't fix it it was just to watch my new memtest at work ;) Vlad Vissoultchev's T(iny) AL(locater): http://repo.or.cz/tinycc.git/commitdiff/cdc16d428f32294 If someone wants to try the difference, comment out tccpp.c:112: #define USE_TAL --- grischka _______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
