Re: [fpc-devel] Debugging Loop Unroll Optimization

On 03.06.2018 17:11, Florian Klämpfl wrote: Am 21.05.2018 um 20:58 schrieb Ondrej Pokorny: In this (your) case I don't expect anything - it is one of FPC's favorites "undefined behaviour" because as documented, it is not allowed to change the loop variable value within a for loop. Yes,

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 21.05.2018 um 20:58 schrieb Ondrej Pokorny: In this (your) case I don't expect anything - it is one of FPC's favorites "undefined behaviour" because as documented, it is not allowed to change the loop variable value within a for loop. Yes, just asking :) In my case (without the I:=1

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 21.05.2018 um 19:27 schrieb Ondrej Pokorny: > Well there is still something left: You are right, variables don't correctly get captured (or rather, don't get captured at all). This is not good. Dirty fix: only unroll loops over local variables when there are no nested procs. But that probably

Re: [fpc-devel] Debugging Loop Unroll Optimization

In that example, I would logically expect an infinite loop.  Realistically, I'm not sure, because you're literally trying to trick the compiler with a construct like that (which all testers should do!) - that one could be fun to test! Gareth aka. Kit On Mon 21/05/18 19:43 , Florian Klämpfl

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 21.05.2018 um 19:27 schrieb Ondrej Pokorny: > On 21.05.2018 18:23, Martok wrote: >> Am 21.05.2018 um 17:44 schrieb Florian Klämpfl: >>> I added raise, exit, goto and label as well. >> Oh, label, right. >> >> I'd say #0033614 can be resolved as "fixed in 39083" and #0033753 as "no >> change >>

Re: [fpc-devel] Debugging Loop Unroll Optimization

Unless I'm missing something, that could be unrolled without any problems.  The only problem that could occur is if Test2 raises an exception (which, as the name implies, is an exceptional situation) or it jumps outside of the procedure, which can only realistically occur in some compiler

Re: [fpc-devel] Debugging Loop Unroll Optimization

On 21.05.2018 18:23, Martok wrote: Am 21.05.2018 um 17:44 schrieb Florian Klämpfl: I added raise, exit, goto and label as well. Oh, label, right. I'd say #0033614 can be resolved as "fixed in 39083" and #0033753 as "no change required" then. Well there is still something left: program

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 21.05.2018 um 17:44 schrieb Florian Klämpfl: > I added raise, exit, goto and label as well. Oh, label, right. I'd say #0033614 can be resolved as "fixed in 39083" and #0033753 as "no change required" then. -- Regards, Martok ___ fpc-devel

Re: [fpc-devel] Debugging Loop Unroll Optimization

On 18/05/18 13:28, Marco van de Voort wrote: In our previous episode, Mattias Gaertner said: ISO7185: "After a for-statement is executed, other than being left by a goto-statement, the control-variable shall be undefined"

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 18.05.2018 um 17:15 schrieb Sven Barth via fpc-devel: > Martok > schrieb > am Fr., 18. Mai 2018, 15:40: > > > Citation: "If the loop was terminated prematurely with an exception or a > > break statement, the loop variable

Re: [fpc-devel] Debugging Loop Unroll Optimization

On 05/18/2018 11:16 AM, Thorsten Engler wrote: The for-loop variable is undefined after the loop if the loop ran to completion. It retains its last value if the loop exited in a controlled way (goto, break, exit, ?) before running to completion. speaking from the peanut gallery, FWIW, i like

Re: [fpc-devel] Debugging Loop Unroll Optimization

> -Original Message- > From: fpc-devel On Behalf > Of Mattias Gaertner > > You forgot the case where the loop was not entered: > > for i:=2 to 1 do ; > > i is now undefined. > > Same for > > for i in emptyset do ; Both are cases of "the loop

Re: [fpc-devel] Debugging Loop Unroll Optimization

" I think based on both documented and observed behaviour, the following definition would be appropriate: The for-loop variable is undefined after the loop if the loop ran to completion. It retains its last value if the loop exited in a controlled way (goto, break, exit, ?) before running

Re: [fpc-devel] Debugging Loop Unroll Optimization

On Sat, 19 May 2018 01:16:00 +1000 "Thorsten Engler" wrote: >[...] > The for-loop variable is undefined after the loop if the loop ran to > completion. It retains its last value if the loop exited in a controlled way > (goto, break, exit, ?) before running to

Re: [fpc-devel] Debugging Loop Unroll Optimization

On 18.05.2018 17:17, Marco van de Voort wrote: To keep in annoying detail mode: for result:=0 to 3 do if x(result) then exit(result) ...is yet another case since the exit(result) could be taken as an explicit assignment of the loopvar to an location outside the loop, after

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 18.05.2018 um 17:15 schrieb Sven Barth via fpc-devel: > Maybe it should also check for goto and at least explicit raise statements? That'd be adding goton and raisen to the check, right? For now, just checking exit seems to be enough to get rid all of the easily testable Lazarus crashes. The

Re: [fpc-devel] Debugging Loop Unroll Optimization

In our previous episode, Mattias Gaertner said: > > Well, well, clearly. One could interpret it that it says that the for > > statement terminates naturally if not forced by break or exit. It doesn't > > say what happens with break or exit. > > If the value of counter is undefined no matter

Re: [fpc-devel] Debugging Loop Unroll Optimization

> It is *not* undefined when the loop is left with break or exit, > that's the point. The ISO is not a very good reference for modern- > ish Pascal. I think based on both documented and observed behaviour, the following definition would be appropriate: The for-loop variable is undefined after

Re: [fpc-devel] Debugging Loop Unroll Optimization

Martok schrieb am Fr., 18. Mai 2018, 15:40: > > Citation: "If the loop was terminated prematurely with an exception or a > > break statement, the loop variable retains the value it had when the > > loop was exited." > As a quick fix, not unrolling loops left with exit

Re: [fpc-devel] Debugging Loop Unroll Optimization

Apologies, I meant it was undefined if the loop exits normally, but retains its current value if terminated prematurely.  Ah well! Admittedly I do like concrete rules, and any situations where something is undefined is explicitly stated.  Hopefully we can put this one to bed now!  Back to

Re: [fpc-devel] Debugging Loop Unroll Optimization

> Sorry to waste your time on this. Don't worry, I like investigating this stuff. I don't like the rule-lawyering that usually follows ;-) > I'm glad it states the for-loop variable will be left undefined - that's > good enough documentation for me. It is *not* undefined when the loop is left

Re: [fpc-devel] Debugging Loop Unroll Optimization

That looks sensible. Sorry to waste your time on this.  I'm glad it states the for-loop variable will be left undefined - that's good enough documentation for me. I wouldn't call it a quick fix... more of fixing an oversight, since I can see the trick of using Result as the for-counter being

Re: [fpc-devel] Debugging Loop Unroll Optimization

> Citation: "If the loop was terminated prematurely with an exception or a > break statement, the loop variable retains the value it had when the > loop was exited." As a quick fix, not unrolling loops left with exit at least fixes this specific situation. This still leaves exceptions raised,

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 18.05.2018 um 14:07 schrieb J. Gareth Moreton: > What's the easiest solution to this? Change the code or change the rule? Follow consensus. There's little point in ignoring 30 years of language development, just because nobody started an ISO committee. In this case: """After a for-statement is

Re: [fpc-devel] Debugging Loop Unroll Optimization

Lawyers or not, well-defined behaviour can only be a good thing for a language.  As for those code snippets in the VCL and the like, unless we want to change the rule so that the for-loop counter has a distinct value afterwards, Result should be explicitly set after the for loop (presumably

Re: [fpc-devel] Debugging Loop Unroll Optimization

On Fri, 18 May 2018 13:28:30 +0200 (CEST) mar...@stack.nl (Marco van de Voort) wrote: >[...] > > > "After the for statement terminates (provided this was not forced by a > > > Break or an Exit procedure), the value of counter is undefined." >[...] > Well, well, clearly. One could interpret it

Re: [fpc-devel] Debugging Loop Unroll Optimization

On 18.05.2018 13:28, Marco van de Voort wrote: In our previous episode, Mattias Gaertner said: ISO7185: "After a for-statement is executed, other than being left by a goto-statement, the control-variable shall be undefined"

Re: [fpc-devel] Debugging Loop Unroll Optimization

In our previous episode, Mattias Gaertner said: > > ISO7185: "After a for-statement is executed, other than being left by a > > goto-statement, the > > control-variable shall be undefined" > > > >

Re: [fpc-devel] Debugging Loop Unroll Optimization

What I've gathered is that with the following routine: function DoSomething: Integer; begin   for Result:=alow to ahigh do    if Something(Result) then exit; end; The issue occurs if "Something(Result)" always returns False and the for-loop exits normally.  While some languages and

Re: [fpc-devel] Debugging Loop Unroll Optimization

On Thu, 17 May 2018 18:34:04 +0200 Florian Klämpfl wrote: >[...] Apparently this mail thread confuses some users: report https://bugs.freepascal.org/view.php?id=33753: > ISO7185: "After a for-statement is executed, other than being left by a > goto-statement, the >

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 17.05.2018 um 21:06 schrieb Florian Klämpfl: > -O3 probably "breaks" a lot of code which exploits the limits of a language- True. I do wonder if it would be good to create some sort of collection of things that are undefined in the core language and how different compilers and dialects handle

Re: [fpc-devel] Debugging Loop Unroll Optimization

> Can you report that to the bugtracker of Lazarus? Sure. Done as https://bugs.freepascal.org/view.php?id=33753 Martok ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 17.05.2018 um 19:01 schrieb Martok: > Same documentation for FPC, > > > But, someone clearly explicitly thought otherwise at some point: Sometime ago, fpc behaved strange in case of for loops and dfa, so it might have been that the

Re: [fpc-devel] Debugging Loop Unroll Optimization

On Thu, May 17, 2018 at 6:01 PM, Martok wrote: > If that gets unrolled, Result is undefined, and whatever it gets assigned to > receives the random content of r/eax. > >Grepping for "for result:=" over the FPC > source tree gives 10 matches, Lazarus has over 100

Re: [fpc-devel] Debugging Loop Unroll Optimization

Same documentation for FPC, But, someone clearly explicitly thought otherwise at some point: That warning is only "wrong" if Result is well-defined

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 17.05.2018 um 18:01 schrieb Martok: > I think I found something, see below. Answering the question first ;-) > > Am 16.05.2018 um 19:20 schrieb Florian Klämpfl: >> How big is the project? Normally, the number of unrolled loops is reasonable >> small so comparing the >> generated assembler

Re: [fpc-devel] Debugging Loop Unroll Optimization

I think I found something, see below. Answering the question first ;-) Am 16.05.2018 um 19:20 schrieb Florian Klämpfl: > How big is the project? Normally, the number of unrolled loops is reasonable > small so comparing the > generated assembler with and without unrolling should be

Re: [fpc-devel] Debugging Loop Unroll Optimization

Am 16.05.2018 um 14:57 schrieb Martok: > Hi all, > > as we have discovered in 0033576 and 0033614, there is a bug somewhere in the > loop unroll optimization pass that only appears in complex enough code. The > problem is, it doesn't happen in the single testsuite test, and the observable >