On 04 Jan 2012, at 15:12, Sergei Gorelkin wrote:
However, you can as well try the attached simple patch. It prevents
temps referenced from 'finally' blocks from being placed to registers.
While I'm not immediately certain how that would be done in the
easiest way, it would be best if that
04.01.2012 15:58, José Mejuto пишет:
Hello FPC,
Tuesday, January 3, 2012, 10:01:54 PM, you wrote:
Do you know which kind of code I must look for to isolate the problem
?
SG> I'd suggest looking at the constructors containing an 'exit' statement,
SG> but I'm not entirely sure.
SG> Does rest
03.01.2012 23:54, José Mejuto пишет:
Hello FPC,
Monday, January 2, 2012, 9:27:50 PM, you wrote:
The solution to optimize the unnecessary finally blocks without
breaking exit behavior is still to
be found.
SG> More sophisticated patch applied in r19955. If you can test
SG> your project with
02.01.2012 14:16, Sergei Gorelkin пишет:
31.12.2011 23:17, José Mejuto пишет:
I'll be very happy in test any change you may want to try before
commit to SVN. This kind of problems seems to be very difficult to
catch, so I'll try to not change my codebase while you investigate in
order to be abl
31.12.2011 23:17, José Mejuto пишет:
SG> Plain removal of this if..else breaks a couple of tests in
SG> the testsuite. But the information you
SG> provided gives some pointers to look at. At least, adding a
SG> check that constructor without
SG> pi_needs_implicit_finally flag doesn't have a
31.12.2011 18:52, José Mejuto пишет:
Hello FPC,
Saturday, December 31, 2011, 3:39:59 PM, you wrote:
SG> r19668 affects codegeneration of constructors and custom enumerators, and
fixes
SG> http://bugs.freepascal.org/view.php?id=20827
SG> The reported location of crash in your case is likely
31.12.2011 16:58, José Mejuto пишет:
Hello Jonas,
Wednesday, December 28, 2011, 2:43:16 PM, you wrote:
JM> The most likely problem is memory corruption by your program.
[...]
JM> give more accurate diagnostics).
A bit more information:
Environment is win32.
The line that raises the excepti
On 28 Dec 2011, at 14:25, José Mejuto wrote:
> To me it looks like the code is trying to free some strings or
> interfaces but at a point where the manager of automated types has
> been "disabled" so the declaration of a new ansistring "reconnects"
> it. Maybe it is a crazy idea but is the only o
