Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp
Am 09.03.2015 um 14:36 schrieb bla...@blaise.ru: FPC trunk r30150, compiled with EXTDEBUG, emits a debug warning for the following program: --8-- type T = interface procedure Bar; end; function Foo: T; begin result := nil end; begin Foo().Bar() // ^-- Warning: tgobj: (FreeTemp) temp at pos -44 is already free ! end. --8-- Does this indicate a problem in the compiler, or is this warning bogus? I'd assume that the warning refers to result := nil in Foo(). Assign something different and try again to find out more. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp
On 09 Mar 2015, at 14:36, bla...@blaise.ru wrote: On 15.01.2012 18:26, Blaise Thorn wrote: I have implemented the support for the Delphi-compatible non- generic closures. I am ready to commit the improved (and fully compilable) version. Per Jonas Maebe's suggestion, I am going to create a new branch (also, last time I tried to commit into the existing closures branch, I was consistently getting 500 Internal Server Error). Do you already have an svn account? begin Foo().Bar() // ^-- Warning: tgobj: (FreeTemp) temp at pos -44 is already free ! end. --8-- Does this indicate a problem in the compiler, or is this warning bogus? It indicates a problem in the compiler. As the message indicates, it means that you (or someone else before you) are trying to free a temp (allocated via tg.gettemp or the like) twice. The generated code will still be ok in this case, but it could lead to trouble in case a temp would be allocated again in between which would happen to get the same address as the old one, since then the second free of the old temp will free the new temp. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp
On 10.03.2015 15:47, Jonas Maebe wrote: Do you already have an svn account? The one I had back in 2012. My old branch is here: http://svn.freepascal.org/svn/fpc/branches/blaise/closures It indicates a problem in the compiler. Thanks. Shall I file it in the bug tracker, then? As the message indicates, it means that you (or someone else before you) are trying to free a temp (allocated via tg.gettemp or the like) twice. I am slightly confused by your choice of the pronoun, so allow me to reiterate: the issue exists in the stock compiler, even without my patches applied. The generated code will still be ok in this case, but it could lead to trouble in case a temp would be allocated again in between which would happen to get the same address as the old one, since then the second free of the old temp will free the new temp. I am not at all familiar with this part of the compiler, so devising a test case, that would result in invalid codegen, would be difficult for me. Based on your explanation, it seems it would be something like Foo().Bar( YieldAnotherTemp() ) assuming that YieldAnotherTemp() is called after Foo()? -- βþ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp
On 10 Mar 2015, at 14:29, bla...@blaise.ru wrote: On 10.03.2015 15:47, Jonas Maebe wrote: Do you already have an svn account? The one I had back in 2012. My old branch is here: http://svn.freepascal.org/svn/fpc/branches/blaise/closures You should still have access to everything under http://svn.freepascal.org/svn/fpc/branches/blaise It indicates a problem in the compiler. Thanks. Shall I file it in the bug tracker, then? Can't hurt. As the message indicates, it means that you (or someone else before you) are trying to free a temp (allocated via tg.gettemp or the like) twice. I am slightly confused by your choice of the pronoun, so allow me to reiterate: the issue exists in the stock compiler, even without my patches applied. Then it will be someone else before you. The generated code will still be ok in this case, but it could lead to trouble in case a temp would be allocated again in between which would happen to get the same address as the old one, since then the second free of the old temp will free the new temp. I am not at all familiar with this part of the compiler, so devising a test case, that would result in invalid codegen, would be difficult for me. Based on your explanation, it seems it would be something like Foo().Bar( YieldAnotherTemp() ) assuming that YieldAnotherTemp() is called after Foo()? It depends on when exactly the second free of the initial temp occurs. A testcase that results in invalid code is not necessary, however. It should be easily debuggable without that (although fixing it may be more tricky). Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp
On 10.03.2015 15:09, Hans-Peter Diettrich wrote: I'd assume that the warning refers to result := nil in Foo(). Wrong. And the comment clearly indicates to which line it refers. This happens because of the call chaining. -- βþ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC programs in OSv
On Wed, 4 Mar 2015 17:32:41 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 4 Mar 2015 16:41:23 +0100 Sven Barth pascaldra...@googlemail.com wrote: [...] In theory: by compiling the RTL with -dFPC_USE_LIBC. [...] My outstanding commit fixes this. Outstanding! :) Now (30159) it fails with: /home/mattias/3.1.1/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/home/mattias/3.1.1/rtl/units/x86_64-linux -Cg -dFPC_USE_LIBC -dx86_64 -dRELEASE -Us -Sg system.pp system.pp(34,2) Fatal: Cannot open include file sysunixh.inc Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC programs in OSv
On 10.03.2015 18:46, Mattias Gaertner wrote: On Wed, 4 Mar 2015 17:32:41 +0100 Mattias Gaertner nc-gaert...@netcologne.de wrote: On Wed, 4 Mar 2015 16:41:23 +0100 Sven Barth pascaldra...@googlemail.com wrote: [...] In theory: by compiling the RTL with -dFPC_USE_LIBC. [...] My outstanding commit fixes this. Outstanding! :) Now (30159) it fails with: /home/mattias/3.1.1/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fix86_64 -FE. -FU/home/mattias/3.1.1/rtl/units/x86_64-linux -Cg -dFPC_USE_LIBC -dx86_64 -dRELEASE -Us -Sg system.pp system.pp(34,2) Fatal: Cannot open include file sysunixh.inc Yes, it fails randomly, because the parameters can not be parsed correctly (some of the passed arguments are randomly missing). I've now finally committed my fix in r30160 which also allows the usage of FPC binaries on OSv (which had originally been the reason I investigated this... but it seems my procrastination took the better of me ^^) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC programs in OSv
On Tue, 10 Mar 2015 19:34:59 +0100 Sven Barth pascaldra...@googlemail.com wrote: [...] Yes, it fails randomly, because the parameters can not be parsed correctly (some of the passed arguments are randomly missing). I've now finally committed my fix in r30160 which also allows the usage of FPC binaries on OSv (which had originally been the reason I investigated this... but it seems my procrastination took the better of me ^^) I get: /home/mattias/3.1.1/fpc/compiler/ppc1 -Ur -Xs -O2 -n -Fux86_64 -Fusystems -Fu/home/mattias/3.1.1/fpc/rtl/units/x86_64-linux -Fix86_64 -FE. -FUx86_64/units/x86_64-linux -Cg -dRELEASE -dFPC_USE_LIBC-dx86_64 -dGDB -dBROWSERLOG -Fux86 -Sew pp.pas pp.pas(247,1) Warning: crtbeginS.o not found, this will probably cause a linking failure pp.pas(247,1) Warning: crtendS.o not found, this will probably cause a linking failure /usr/bin/ld: warning: ./link.res contains output sections; did you forget -T? pp.pas(247,1) Fatal: There were 2 errors compiling module, stopping Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp
On 15.01.2012 18:26, Blaise Thorn wrote: I have implemented the support for the Delphi-compatible non-generic closures. I am ready to commit the improved (and fully compilable) version. Per Jonas Maebe's suggestion, I am going to create a new branch (also, last time I tried to commit into the existing closures branch, I was consistently getting 500 Internal Server Error). I would like to acknowledge the participation of Craig Peterson of Scooter Software, who was persistent enough to nudge me into completing this, provided additional testing, and offered a compensation for the time spent on the last stage. Whilst I mutilate the source code into compatibility with the FPC coding style, I have some questions that can be raised even before the code is committed. FPC trunk r30150, compiled with EXTDEBUG, emits a debug warning for the following program: --8-- type T = interface procedure Bar; end; function Foo: T; begin result := nil end; begin Foo().Bar() // ^-- Warning: tgobj: (FreeTemp) temp at pos -44 is already free ! end. --8-- Does this indicate a problem in the compiler, or is this warning bogus? -- βþ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
