On 21/01/2014 21:20, Florian Klämpfl wrote:
Am 19.01.2014 18:01, schrieb Martin:
In each of them GetNextInstruction(p, hp1) could be executed.
If I counted correct, it can be called up to 6 times for each a_mov.
On the other hand:
- no code in this case block, is ever executed, if it does not s
On 21/01/2014 21:28, Florian Klämpfl wrote:
Am 20.01.2014 01:18, schrieb Martin:
It used
(taicpu(p).oper[1]^.reg<>taicpu(hp1).oper[0]^^.ref^.base) and
(taicpu(p).oper[1]^.reg<>taicpu(hp1).oper[0]^^.ref^.index) then
but should only compare the supregister part
I replaced that
not(RegInOp(getsupr
On 21/01/2014 23:37, Jonas Maebe wrote:
On 22 Jan 2014, at 00:06, Martin Frb wrote:
So then a patch would be accepted to move the check for
GetNextInstruction(p, hp1)
to the start, and have one single such condition, in one IF block, that will
contain all the others?
The main issue with
Starting one by one.
This is the simplest of the changes. In addition to the patch in this
message, what is needed to get it committed?
On 10/11/2013 23:52, Jonas Maebe wrote:
On 10 Nov 2013, at 22:42, Martin wrote:
Why is the
movl%eax,-12(%ebp)
generated at the start of i:=i+1
The s
On 21/01/2014 21:28, Florian Klämpfl wrote:
Can you post some example code? It might be worth to think about
improving this already in at the node level.
While getting examples, another issue:
with -O2 , -O3 or -O4
Note the
movl%eax,%edx
movl%edx,%eax
with -O1 it is
mov
On 21/01/2014 23:27, Martin Frb wrote:
On 21/01/2014 21:28, Florian Klämpfl wrote:
Am 20.01.2014 01:18, schrieb Martin:
It used
(taicpu(p).oper[1]^.reg<>taicpu(hp1).oper[0]^^.ref^.base) and
(taicpu(p).oper[1]^.reg<>taicpu(hp1).oper[0]^^.ref^.index) then
but should only compare the
On 22/01/2014 00:46, Ralf Quint wrote:
On 1/21/2014 4:23 PM, Martin Frb wrote:
Sorry, but those two code blocks are NOT identical as you claim.
At least in the snippets below, GetNextInstruction is called at least
twice in the OLD snippet, not only once as your supposed NEW snippet
does. It is
On 22/01/2014 21:22, Florian Klämpfl wrote:
Am 22.01.2014 00:06, schrieb Martin Frb:
On 21/01/2014 21:20, Florian Klämpfl wrote:
Am 19.01.2014 18:01, schrieb Martin:
In each of them GetNextInstruction(p, hp1) could be executed.
If I counted correct, it can be called up to 6 times for each
On 22/01/2014 21:29, Florian Klämpfl wrote:
Am 22.01.2014 04:06, schrieb Martin Frb:
On 21/01/2014 21:28, Florian Klämpfl wrote:
Can you post some example code? It might be worth to think about
improving this already in at the node level.
While getting examples, another issue:
with -O2
On 23/01/2014 19:35, Florian Klämpfl wrote:
Am 22.01.2014 23:22, schrieb Martin Frb:
One of the optimizations you said it where better avoided to be created
in first. I agree.
Only, even if that is archived at some time, who guarantees that it will
not be back (and unnoticed)?
Are there tests
On 23/01/2014 20:04, Florian Klämpfl wrote:
Am 23.01.2014 20:52, schrieb Martin Frb:
On 23/01/2014 19:35, Florian Klämpfl wrote:
I think this is hard to achive as well.
Why?
I consider it as complicated and it covers only cases one can forsee.
Some statistical analysis of benchmark timings
On 23/01/2014 20:34, Florian Klaempfl wrote:
Yes and no. It is extra code and extra code is always bad ;) and it
requires a separate compiler run. I wouldn't waste effort in it.
testcase are extra code too. ;) scnr
Ok, i see what you mean. No problem. It was just an idea.
On 22/01/2014 21:23, Florian Klämpfl wrote:
Submit them to a bug report, I can look during the weekend into them.
Done: 0025584, 0025586, 0025587
http://bugs.freepascal.org/view.php?id=25584
http://bugs.freepascal.org/view.php?id=25586
http://bugs.freepascal.org/view.php?id=25587
__
On 23/01/2014 22:26, August Oktobar wrote:
Hello, I have seen your mails about peephole optimization, so I wonder
if you could look at this reports
http://bugs.freepascal.org/view.php?id=23595
or perhaps optimize slow array access using operator [] (it is faster
to use pointer arithmetics)
t
On 24/01/2014 00:17, August Oktobar wrote:
"2) Reporter's assumption about fstp is wrong: the first fstp
instruction removes value from fpu stack, so it cannot be used for the
second time without first reloading value onto stack."
Compiler should reuse loaded value (a[i]) and store to a[i] usi
On 24/01/2014 01:03, Martin Frb wrote:
Until that is done, your best choice, if you need the speed is to do
this by hand:
or better
if cnt = 0 then exit;
tmpptrA := @a[0];
tmpptrB := @b[0];
for i := 0 to cnt - 1 do
begin
tmpVAlue := tmpptrA^ + tmpptrB^;
tmpptrA^ := tmpVAlue
http://www.freepascal.org/docs-html/ref/refch12.html#x120-1312
lists
Table 12.1: Precedence of operators
OperatorPrecedence Category
---
On 03/02/2014 01:42, Martin Frb wrote:
http://www.freepascal.org/docs-html/ref/refch12.html#x120-1312
lists
Table 12.1: Precedence of operators
OperatorPrecedence Category
On 03/02/2014 07:58, Michael Van Canneyt wrote:
On Mon, 3 Feb 2014, Martin Frb wrote:
This does not include:
^ deref
- unary minus
. accessing a member of a class/record (not unary)
To my knowledge, the . and ^ are not considered operators, they are
"part of the identifier".
O
On 03/02/2014 10:48, Sven Barth wrote:
So unary minus (and also unary plus which is a valid operator as
well!) binds stronger than multiplication.
Just using -al
c := -a *b;
c := (-a) *b;
c := -(a *b);
The unary - is applied first. Though it makes no difference to the result.
However with
On 03/02/2014 13:47, Jonas Maebe wrote:
On 03 Feb 2014, at 14:28, Martin Frb wrote:
The reason I did get to that, is because I have to reproduce the
behaviour (for fpdebug).
And when scanning/evaluating a pascal expression/statement, it works
well to handle the "." (and also
On 03/02/2014 14:07, Martin Frb wrote:
On 03/02/2014 13:47, Jonas Maebe wrote:
On 03 Feb 2014, at 14:28, Martin Frb wrote:
The reason I did get to that, is because I have to reproduce the
behaviour (for fpdebug).
And when scanning/evaluating a pascal expression/statement, it works
well to
Anybody?
Is this designed? Or is this a bug? Shall I put it on Mantis?
On 26/01/2014 19:48, Martin Frb wrote:
TFoo1 is a sub range of FFoo
And it seems to match both TFoo and variant.
project1.lpr(24,3) Error: Can't determine which overloaded function
to call
project1.lpr(15,11) Hint:
On 03/02/2014 07:58, Michael Van Canneyt wrote:
As for unary minus: this is the same as a binary minus in arithmatic
expressions.
On 03/02/2014 14:37, Sven Barth wrote:
Nevertheless FPC provides the correct operator precedence (no matter
whether overloading is used or not, because that is done
On 03/02/2014 15:38, Dmitry Boyarintsev wrote:
On Mon, Feb 3, 2014 at 10:25 AM, Martin Frb <mailto:laza...@mfriebe.de>> wrote:
It does not state if or if not it is an operator. And also give no
indication on its precedence, or if it is applied before or after
operators.
On 03/02/2014 16:02, Martin Frb wrote:
@a^ always works. All I was asking is if the documentation should
state it more clearly that ^ is (As part of the identifier) done before ^
done before @
of course.
For the rest, I am happy, never mind, if it is an operator or not
On 03/02/2014 15:25, Martin Frb wrote:
On 03/02/2014 14:37, Sven Barth wrote:
Nevertheless FPC provides the correct operator precedence (no matter
whether overloading is used or not, because that is done at a
different level of the parser):
- power
- unary plus/minus
- product/divison
.
Original Message
Subject:Re: [Lazarusdev] crash in View Forms Dialog - codetools
Date: Thu, 06 Feb 2014 00:26:34 +
From: Martin Frb
Reply-To: Lazarus Developers List
To: Lazarus Developers List
On 05/02/2014 23:43, Martin Frb wrote:
On 05/02/2014 23:29
http://www.freepascal.org/docs-html/prog/progsu58.html#x64-630001.1.58
Example:
{$OPTIMIZATION ON}
is equivalent to
{$OPTIMIZATION 2}
"2" is not in the list of supported keywords.
And at least {$OPTIMIZATION 1} gives an compile error
___
fpc-
On 06/02/2014 17:48, Martin Frb wrote:
http://www.freepascal.org/docs-html/prog/progsu58.html#x64-630001.1.58
Example:
{$OPTIMIZATION ON}
is equivalent to
{$OPTIMIZATION 2}
"2" is not in the list of supported keywords.
And at least {$OPTIMIZATION 1} gives an com
http://www.freepascal.org/docs-html/ref/refse67.html#x124-13400012.4
In general, the type size of the expression and the size of the type
cast must be the same. However, for ordinal types (byte, char, word,
boolean, enumerates) this is not so, they can be used interchangeably.
That is, the foll
Below works with 2.6.2 but not with trunk
Is that indented?
the wiki says
Default values are now properly typechecked
* *Old behaviour*: The compiler did not detect default values for
parameters of which the type did not in any way correspond to the
parameter type.
* *New
On 08/02/2014 19:25, Martin Frb wrote:
In the below (first) example "longint(1)" and TFoo have the same size.
Yet in the first example they fail. This is not covered by the
documentation.
The doc even gives examples involving typecasting constant values.
Byte(’A’)
given th
On 08/02/2014 21:59, Hans-Peter Diettrich wrote:
Typecasts can be further restricted to *compatible* types. Here
numeric types seem to be compatible with other numeric types, but not
with structured types (records...).
Well than that needs to be added to the docs. I have no problems with
it
project1.lpr(5,19) Error: Duplicate identifier "Foo"
Now the interesting part is that ONLY happens if the two procedures are
part of a class AND the parmeter has the same name as the procedure.
If I declare 2 procedures like that outside a class, then there is no error.
Also there is no error,
I am trying to figure out the internal representation of these. (So they
can be converted, including conversion form sizes not present in fpc)
They are all floating point? Pascal has no fixed point? (nevertheless,
rules for fixed point may also be of interest)
dwarf2 says it is specified in e
PING
On 08/02/2014 19:38, Martin Frb wrote:
Below works with 2.6.2 but not with trunk
Is that indented?
Surely someone knows, if that is intended?
the wiki says
Default values are now properly typechecked
* *Old behaviour*: The compiler did not detect default values for
On 13/02/2014 07:40, Sven Barth wrote:
Jonas is currently on vacation and he's the one who implemented it.
You could try to crosstest with Delphi to see whether we are missing
something.
I only have Turbo Delphi, and that does not seem to have operator
overloading at all.
_
Just found that the below works.
Note, that the result type of "a" (overridden) is different.
Well, TFoo2 will always satisfy the needs of TFoo, so it seems save. I
still found it surprising. Is it intended?
program Project1;
type
TFoo= class
public
function a: TFoo; virtual;
end;
On 04/03/2014 14:52, Mattias Gaertner wrote:
The Lazarus team is glad to announce the release of Lazarus 1.2.
We are news worthy (german):
http://www.heise.de/open/meldung/Lazarus-IDE-fuer-Pascal-und-Object-Pascal-in-Version-1-2-veroeffentlicht-2134703.html?wt_mc=rss.open.beitrag.rdf
___
building fpc trunk 27128
on win 32bit vista
with
make.exe all LINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT="-gl -gw
-godwarfsets -O-1 -Cr"
Start compiling package fcl-xml for target i386-win32.
Compiling fcl-xml\BuildUnit_fcl_xml.pp
Compiling .\fcl-xml\src\xmlutils.pp
Th
The below program compiles fine (and generates no warning (fpc 2.6.2 /
win 32)
"c" is an open array. But there is no warning when assigning the
[address of c] to a [pointer to dyn array].
Assuming that type safety checks are performed, I would expect a working
pointer. But it does not. The p
On 30/03/2014 14:35, Jonas Maebe wrote:
On 30/03/14 15:24, Martin Frb wrote:
The below program compiles fine (and generates no warning (fpc 2.6.2 /
win 32)
It only compiles fine with the (default) {$t-}. If you add {$t+}, it
doesn't compile. Without typed pointers, the result o
On 31/03/2014 07:28, Michael Van Canneyt wrote:
On Sun, 30 Mar 2014, Martin Frb wrote:
Slight change, and I get
Fatal: Compilation aborted
procedure Foo(var c: array of integer; var c1: PA);
begin
writeln( (@c)^[1] );
If you are counting on the implicit pointer=array as in C, then
On 31/03/2014 14:07, Jonas Maebe wrote:
On 31 Mar 2014, at 14:53, Martin Frb wrote:
But this is not about the question if this works. It would be fine if
it gave a proper error. But an "Internal Error"? That seems to be a bug.
You said that you got "Fatal: Compilation aborted
Just asking this again, as I did not get any answer yet?
Is that the indented behaviour, and if so what is the reasoning for it?
Original Message
Subject:overload question (variant vs enum subrange)
Date: Sun, 26 Jan 2014 19:48:42 +
From: Martin Frb
To
-devel] override works, even if result type changed?
Date: Sun, 23 Feb 2014 16:56:26 +
From: Martin Frb
Reply-To: FPC developers' list
To: FPC developers' list
Just found that the below works.
Note, that the result type of "a" (overridden) is different.
Wel
On 31/03/2014 16:42, Howard Page-Clark wrote:
This compiles here (FPC 2.6.5, Win32), and produces the output "101"
with no errors.
You are right, I just run with the setting I have in my IDE, without
further testing.
Just testing the compilation, not running the reslt for now:
This is goo
On 31/03/2014 16:54, Martin Frb wrote:
C:\FPC\rel_2_6_4\gw\bin\i386-win32\fpc.exe -Cr project1.lpr
Compiling project1.lpr
Fatal: Compilation aborted
An unhandled exception occurred at $004B352B :
EAccessViolation : Access violation
$004B352B
$00440720
$004E9F72
$004EC4B8
$004EC4CC
On 31/03/2014 20:29, Sergei Gorelkin wrote:
31.03.2014 17:32, Martin Frb пишет:
Just asking this again, as I did not get any answer yet?
Is that the indented behaviour, and if so what is the reasoning for it?
This behavior is hardly intended.
To get clues about what's going on, yo
C:\FPC\SVN\fpc_2.6.4\rtl\win\wininc\defines.inc
line 5669 (in 3.6.4)
{ our own invention }
FLAG_TRACE_BIT = $100;
This is only there for 32 bit and wince, but not for win64.
But the problem is finding out what it actually means. All googling has
not brought any definition to it.
From
On 01/04/2014 18:44, Dmitry Boyarintsev wrote:
To add to that.
*nixes are using ptrace() function and PTRACE_SINGLESTEP request.
I do believe that setting EFlag (FLAG_TRACE_BIT for x86 machines)
would work for *nix systems (didn't try myself), but respecting
defined API is always a better appr
Since I switched to 2.6.4 (win 32 vista), I had several occurrences of
-break-insert
"\"B:/lazarus_latest/components/fpdebug/fppascalbuilder.pas\":387
^done,bkpt={number="12",type="breakpoint",disp="keep",enabled="y",addr="0x0055",file="fppascalbuilder.pas",line="387",times="0,original-loc
Is the following supposed to give a range check? 2.6.4 on win
The value is correct for a DWord.
program Project1;
{$R+}
uses sysutils;
var
n: DWORD;
s: String;
begin
n := $C2001122;
s := Format('%x', [n]); // range check here
writeln(s);
readln;
end.
___
Just seen http://forum.lazarus.freepascal.org/index.php?topic=24191
trunk (2 or 3 weeks old) indeed compiles the below.
Looking at the SetLength line: Why does it allow the "." ?
program Project1;
type
T1 = array of integer;
T2 = array of T1;
T3 = array of T2;
var
a: T3;
begin
SetLeng
Just seen http://forum.lazarus.freepascal.org/index.php?topic=24191
trunk (2 or 3 weeks old) indeed compiles the below.
Looking at the SetLength line: Why does it allow the "." ?
program Project1;
type
T1 = array of integer;
T2 = array of T1;
T3 = array of T2;
var
a: T3;
begin
SetLeng
Just been looking at this, and trying to thing of how to catch in the
debugger.
From a very brief look at the sources (please correct me, if I got it
wrong, or missed anything)
An error handler is installed to the OS, the handler is
function syswin32_i386_exception_handler(excep : PExceptionP
On 13/04/2014 15:49, Sergei Gorelkin wrote:
If so, how can the debugger get notified (before the longjmp), in a
way, that it can get the address
where the problem occurred?
with raise exception the debugger can set a breakpoint, because raise
exception is defined [public
alias ...] so the d
Sorry.
But the below on hold.
I just found the log at the issue. And it seems fpc_raise was called.
My fault
On 13/04/2014 15:58, Martin Frb wrote:
On 13/04/2014 15:49, Sergei Gorelkin wrote:
If so, how can the debugger get notified (before the longjmp), in a
way, that it can get the
On 13/04/2014 16:02, Martin Frb wrote:
Sorry.
But the below on hold.
I just found the log at the issue. And it seems fpc_raise was called.
My fault
OK, I excuse it by being Sunday afternoon. reread. Definitely not called.
On 13/04/2014 15:58, Martin Frb wrote:
On 13/04/2014 15:49
On 13/04/2014 16:54, Sergei Gorelkin wrote:
Since the new exception handling is compilant with "official way to do
it", I'd expect the debugger to be notified about exception by Windows
directly. But I have no idea about how gdb is compatible with that.
Maybe it must be configured in certain wa
From todays trunk (if not using 2.6.4 nor 2.6.2):
The only supported starting compiler version is 2.6.2
But 2.6.4 is out, so the message should be updated?
(The check works, 2.6.4 can be used as start compiler)
___
fpc-devel maillist - fpc-devel@lis
Using 2.6.4 as starting compiler.
Attempting to build 2.7.1 rev 27596
How to I prevent the option from being passed to the starting compiler?
SET FPC=c:\FPC\SVN\ppc386_2_6_4.exe
make clean
make.exe allLINKSMART=1 CREATESMART=1 DEBUG=1 OPTIMIZE=0 OPT="-gl
-O4"
C:/FPC/SVN/trunk_build/rm.e
I added some code to the debugger, to allow stepping from a risen
exception, to a finally or except block.
And also to step correctly from the end of finally (reraise) to the next
finally/except.
However, the compiler does not add lineinfo for the finally
(FPC_POPADDRSTACK) or the end (reraise
In the below example range and overflow checks are off.
The "a-b" line gives the result "2". (As expected after the overflow)
Doing the same operation with constants, does not compile, due to an
overflow error (despite $Q-). Why?
program Project1;
{$R-}{$Q-}
var a, b: qword;
begin
a := 1;
http://www.freepascal.org/docs-html/rtl/heaptrc/environment.html
I was comparing the keywords accepted in the environment with the list
of options that exist in the unit.
The following can be set by env, but is not in the doc (based on 2.7.1)
HaltOnNotReleased : boolean = false;
Could/Shou
On 22/04/2014 08:12, Michael Van Canneyt wrote:
On Mon, 21 Apr 2014, Martin Frb wrote:
About:
tracesize = 8;
This is currently used in type definition
theap_mem_info = record
calls: array [1..tracesize] of codepointer;
So it can not be changed at runtime.
Without any intend of
http://bugs.freepascal.org/view.php?id=26080
Reading this bug, I came to an interesting question. (Purely out of
academic interest / not really interested in the final decision to the bug)
My understanding:
A property guarantees that the accessor can be changed between "direct
field access" a
Please forget the below. I found the error in my thinking.
On 28/04/2014 02:12, Martin Frb wrote:
http://bugs.freepascal.org/view.php?id=26080
Reading this bug, I came to an interesting question. (Purely out of
academic interest / not really interested in the final decision to the
bug
see subject
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
When FPC generates dwarf 3, it does use DW_AT_data_location for dynamic
array.
That leads to gdb reporting "a=b" to be false, after the below code.
(with dwarf 2 gdb compares the pointer, and returns true)
var a,b: array of Integer;
SetLength(a,3);
b:=a;
With that gdb does no longer know t
?
IIRC the same discussion was once done for TObject, but I do not
remember the outcome
--
On 08/05/2014 12:32, Jonas Maebe wrote:
On 06 May 2014, at 01:29, Martin Frb wrote:
When FPC generates dwarf 3, it does use DW_AT_data_location for
dynamic array.
That leads to gdb
On 08/05/2014 20:34, Jonas Maebe wrote:
On 08/05/14 16:10, Martin Frb wrote:
Indeed there is a workaround that can be applied, but it would mean
extra slowdown, as additional ptype must first be sent to gdb to find
out, if it an dynarray = otherdyn.
I understand it's annoying, but I don&
On 08/05/2014 21:11, Martin Frb wrote:
So the entire point is, the debugger should know that they are pointers.
Hidding this from the debugger gets wrong results.
Besides that GDB fails on those anyway (at least the gdb I have). Here
is another one, that does not (and can not) work with the
On 29/10/2014 13:03, Sven Barth wrote:
On 28.10.2014 09:57, Hans-Peter Diettrich wrote:
Sven Barth schrieb:
Take unit Typinfo for example where quite some methods take a TObject
instance.
The TypInfo methods can determine the exact type of their arguments, and
act inside accordingly.
If you
There is a bug report, where the user says he gets this error.
http://bugs.freepascal.org/view.php?id=27003#c79020
He may not have the latest Lazarus, and he still has to report his fpc
version, but terminal detection does not seem to have changed that much
within 2.6.x.
I did ask him for som
On 09/11/2014 11:25, Mattias Gaertner wrote:
Yes, that's logical.
It seems Martin thinks that the compiler needs a terminal. Why
does the compiler use poNewConsole?
It is about starting the debugger (if I read the issue correct).
And actually, this is very old code, and has not been reviewed
On 09/11/2014 09:18, Michael Van Canneyt wrote:
What is there to look at ?
There must be one of the 8 (!) supported terminal programs in the
path. The error message indicates that there is no such program. You
can't get more clear than that, I would think ?
Well to me this error says, this
^X (where X can be (almost?) any letter results in a char (^A=^Z =
control chars)
This also works for none a-z letters. The compiler generates chars.
The only exception is ^{ standalone this is a char. But ^{$ is not a
char followed by $, but a ^ followed by directive.
Yet this is apparently
This is based on a report I got. I can not reproduce myself. (I bcc the
reporter, and hope he will comment)
ON a 664 bit amd linux,
fpc_2.6.4-140420_amd64.deb (apparently the one from Lazarus sourceforge)
The problem started with an error launching the debugger.
Apparently the error occurs onl
On 16/03/2015 22:03, Martin Frb wrote:
Further debugging was done, and the value of
FDbgProcess.FOutputStream.FHandle
was inspected immediately after
TProcess.Execute
It was zero already.
It is my understanding (from browsing the code), that if
TProcess.Execute is succesful, the handle
On 17/03/2015 21:00, Marco van de Voort wrote:
Or could an Handle (active/all ok) be 0?
0 is standard input.
Ah, except, if stdiin is closed, it can go to whatever handle is next
And I have to go and fix some 10 year old code (that now started failing)
___
On 17/03/2015 21:04, Martin Frb wrote:
On 17/03/2015 21:00, Marco van de Voort wrote:
Or could an Handle (active/all ok) be 0?
0 is standard input.
Ah, except, if stdiin is closed, it can go to whatever handle is next
Are there any values that are known to be ont a handle?
On windows
On 17/03/2015 22:57, Marco van de Voort wrote:
In our previous episode, Martin Frb said:
Are there any values that are known to be ont a handle?
On windows codetools find InvalidHandleValue = -1
But on Linux I found nothing like this.
Given that fpselect is documented to have a bit-array of
What are the scoping rules?
Example:
TLazStorageMemBase = object
private
const
CNT_OFFS = SizeOf(Pointer);
DATA_OFFS = CNT_OFFS + (2 * SizeOf(Integer));
private
FMem: PByte;
function GetCapacity: Integer; inline;
function GetCount: Integer; inline;
.
end;
ge
Are there any known conditions, in which inlining is applied, despite a
{$INLINE off}
on top of the unit?
(fpc trunk and 2.6.4)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
On 09/05/2015 19:54, Martin Frb wrote:
It does not work for me in units. fpc trunk r30815.
If I copy all the code into the main project, then it works (and I get
all the hints, about inlining disabled.).
But the above, stopping with the debugger, and stepping in:
- there is on "
What is supposed to happen if the 2nd argument is negative?
program Project1;
uses sysutils;
var a: LongInt;
begin
a := StrToInt('-1');
WriteLn(2 << a);
WriteLn(2 << -1);
ReadLn;
end.
prints:
0
4294967296
"2 << a" translates to "shl eax,cl" (cl being loaded with the result
from strtoint)
So
On 19/05/2015 09:22, Mark Morgan Lloyd wrote:
Jonas Maebe wrote:
Martin Frb wrote:
What is supposed to happen if the 2nd argument is negative?
I would propose to document it as "undefined behaviour", just like C
does (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
On 19/05/2015 11:03, Adriaan van Os wrote:
the cpu, so if you want to guarantee consistent behaviour on all
platforms, you can no longer just emit a shift left/right instruction
and have to add all kinds of checks.
Maybe we should support emitting range checks for the right operand
though (
fpc 3.1.1 on i386
-O3
function FOO: Boolean; inline;
begin
Result := FMem <> nil;
end;
function BAR: TPItemT;
begin
if FOO
then Result := nil
else Result := TPItemT(FMem.FirstItemPointer + (Index *
FItemSize.ItemSize));
end;
generates something like:
005EACF0 833A00
On 19/05/2015 13:56, Jonas Maebe wrote:
On x86-64, x shr 64 = x, for any value of x. On i386, x shr 32 = x,
for any value of x. For PowerPC (32 bit), x shr y = 0 if bit 5 of y is
set, otherwise it's (x shr (y mod 32)). Really, there are very good
reasons to treat this kind of stuff as undefi
On 19/05/2015 14:23, Jonas Maebe wrote:
Martin Frb wrote on Tue, 19 May 2015:
005EACF0 833A00 cmp dword ptr [edx],$00
005EACF3 0F95C0 setnz al
005EACF6 84C0 test al,al
005EACF8 7509 jnz +$09
Is that something that
On 21/05/2015 15:46, Martin Frb wrote:
If I recompile I can see that LazListClasses is recompiled (hints are
produced for the unit)
But TestLazStorageMemCase1 is not recompiled, and the debugln still in
place.
fpc revision 30815
___
fpc-devel
Reading
http://forum.lazarus.freepascal.org/index.php/topic,28740.msg180163.html#msg180163
and http://bugs.freepascal.org/view.php?id=28279
I did some tests and found something related, that I believe to be a
bug. 2.6.4 and trunk (few weeks old)
Could someone please confirm?
The line
s1 :=
On 13/06/2015 10:05, Jonas Maebe wrote:
Martin Frb wrote:
ebx is a temp copy of s1, but then f1 becomes nil, and ebx points to
freed memory.
It's because "out" finalises on the caller side (due to its COM
origin, I guess) while value parameters get their reference count
i
On 13/06/2015 09:31, Florian Klämpfl wrote:
It is similar to
type
tarray = array [1..10] of longint;
procedure p(const a1 : tarray;var a2 : tarray);
begin
a2[1]:=4321;
writeln(a1[1]); // surprise
end;
var
arr : tarray;
begin
arr[1]:=1234;
p(arr,arr);
end.
I don
On 13/06/2015 09:31, Florian Klämpfl wrote:
The only way to prevent this (of course, such a simple case could be detected
by the compiler but
one can always construct an example which works around this detection), is to
turn off the const
optimization that const allows the compiler to pass only
On 13/06/2015 10:05, Jonas Maebe wrote:
Martin Frb wrote:
ebx is a temp copy of s1, but then f1 becomes nil, and ebx points to
freed memory.
It's because "out" finalises on the caller side (due to its COM
origin, I guess) while value parameters get their reference count
i
On 13/06/2015 15:12, Michael Van Canneyt wrote:
Note the 0 !
Secondly, the section about 'out' parameters is very old; there were
not nearly so much managed types at the time.
I will update it, I was just documenting the new string types anyway.
The above will nicely illustrate the point.
1 - 100 of 379 matches
Mail list logo
