Re: [fpc-devel] FPC trunk build failed

On 17/05/18 22:22, Dimitrios Chr. Ioannidis via fpc-devel wrote: > Hi, > > I tried to build trunk today and I got the following error : > >> aasmcpu.pas(1540,31) Error: Compilation raised exception internally >> Fatal: Compilation aborted >> An unhandled exception occurred at $004B6EEE: >>

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] FPC trunk compiler slower than 3.0.4

On 18/05/2018 17:32, Ondrej Pokorny wrote: Hello, I observe that FPC trunk compiler is about 65-70% (factor 1.65-1.7) slower than FPC 3.0.4 compiler. E.g. building Lazarus IDE takes on my machine: 1:00 with FPC 3.0.4 1:40 with FPC trunk Do you observe the same? Any hints why? Is anybody

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

[fpc-devel] FPC trunk compiler slower than 3.0.4

Hello, I observe that FPC trunk compiler is about 65-70% (factor 1.65-1.7) slower than FPC 3.0.4 compiler. E.g. building Lazarus IDE takes on my machine: 1:00 with FPC 3.0.4 1:40 with FPC trunk Do you observe the same? Any hints why? Is anybody worried about the speed? Is anybody working on

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] Kit's ambitions!

What you've shown suggests that the routine is NOT inlined, as it's building a stack frame and the 'add' operations at the very top looks like padding (they're all zeroes in machine code) to align the procedure to a 16 byte boundary, and would crash the program if directly executed. Look at

Re: [fpc-devel] Kit's ambitions!

From: fpc-devel On Behalf Of Wolf Sent: Friday, 18 May 2018 07:27 This is the disassembly of function GetProcessorUsed: longint;inline; Unless you advise me otherwise, I take the absence of function GetProcessorUsed: longint;inline; mentioned

Re: [fpc-devel] Kit's ambitions!

Hi Gareth, This is the disassembly of /function GetProcessorUsed: longint;    inline; /Unless you advise me otherwise, I take the absence of /function GetProcessorUsed: longint;    inline; /mentioned anywhere in this screen print that /GetProcessorUsed/ is indeed inlined. And in the face of