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:
>> EAcc
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 th
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 worr
> -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 run to completion". Just because "completio
"
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 to
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 completion.
You forgot the case wh
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 whic
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 "
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
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 what,
> 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 th
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 at least fixes this
> specif
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 more
> 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 wi
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 ve
> 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, but
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
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
peop
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 tha
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"
http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Declarations_and_Sta
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"
> >
> > http://docwiki.embarcadero.com/RADStudio/Tokyo/en/Declarations_and_Statements_(Delphi)#For_Statement
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
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 anywhere in this screen print
that GetProc
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
24 matches
Mail list logo