On 04/04/2024 16:39, J. Gareth Moreton via fpc-devel wrote:
Essentially, an arithmetic overflow is happening. Since the largest
Int64 possible is 9,223,372,036,853,775,807, going one above that (the
result to abs(low(int64))) wraps back around to
-9,223,372,036,853,775,808.
Internally, you
The below writes: -9223372036854775808
Shouldn't absolute return a positive number?
program Project1;
begin
writeln( abs(low(int64)) );
end.
Seems
writeln( abs(low(longint)) );
also returns negative...
___
fpc-devel maillist -
On 20/03/2024 10:14, Michael Van Canneyt via fpc-devel wrote:
I just did the same for 55 platforms (cross-compile), on ubuntu. All
work without errors ?
Apologies, probably my fault. I export the sources from git before
build, but did not remove old files. Starting without any old files in
Older Ubuntu, trying to update (starting compiler is 3.2.2)
make clean
make all OPT=" -O-1 -gw3 "
make install INSTALL_PREFIX=/home/m/fpc/
Compiling ./fcl-web/src/fcm/fpfcmstrings.pp
Writing Resource String Table file: fpfcmstrings.rsj
Compiling ./fcl-web/src/jwt/fpjwarsa.pp
On 19/03/2024 15:41, Mattias Gaertner via fpc-devel wrote:
On 19.03.24 14:58, Maxim Ganetsky via fpc-devel wrote:
[...]
#7 944.7 fpmake.pp(228,5) Error: Identifier not found "T"
Ah, you are using fpc 3.3.1 to compile it.
Fixed.
But I get strange linker errors compiling webidl2pas:
(9015)
https://www.freepascal.org/docs-html/rtl/system/default.html
Default is a compiler intrinsic: it returns for every type T a default
value. In essence, this is a block of memory that is zeroed out. It
can be used to correctly initialize any type, and more importantly, a
managed type. It also
The code below (avail as download, wrongly reported at
https://gitlab.com/freepascal.org/fpc/source/-/issues/40634#note_1777253148
=> gen331_b.zip )
compiles in in 3.2.3, but not in 3.3.1
As for as I am concerned 3.3.1 is right. But should that change be
mentioned on the user changes
https://www.freepascal.org/docs-html/ref/refse35.html
Strict Protected
Is the same as Protected, except that the members of a Protected
section are also accessible to other classes implemented in the
same unit. Strict protected members are only visible to descendent
classes, not
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40768
Are there any defaults, with which precision each float type
(single/double/extended) should be printed?
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
The below leads to debug info reporting TAlphaColor as Cardinal.
Maybe it could be changed (like TColor is a distinct type)?
unit System.UITypes;
Type
...
TAlphaColor = Cardinal;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://www.freepascal.org/docs-html/rtl/system/inc.html
- says it operates on pointers
- also gives examples for unsigned types such as word
But can it be used to increment a QWORD?
Inc(FAddress, (Opcode div FOwner.FLineInfo.LineRange) *
FOwner.FLineInfo.MinimumInstructionLength);
https://www.freepascal.org/docs-html/ref/refsu3.html
Is this list complete/correct?
1)
It lists bitpacked, but
program foo; var bitpacked: integer; begin end;
gives an error.
I thought modifiers can be used as var names?
2)
Is there, or has there once been?
(found in the synedit
On 11/01/2024 17:30, Marco van de Voort via fpc-devel wrote:
Let me state it more clearly:
The point is that given a precompiled Linux RTL, to my best knowledge
you can't test any define outside the FPC build environment to see if
the RTL was compiled with FPC_USE_LIBC or not. Maybe there
On 11/01/2024 16:34, Marco van de Voort via fpc-devel wrote:
Op 11-1-2024 om 15:48 schreef Martin Frb via fpc-devel:
- Can (on any linux/unix) "uses SysCall" be compiled (without error)
You can test that yourself on a Linux system by compiling a cycle with
-dFP
Is this page up to date?
https://www.freepascal.org/docs-html/prog/progap7.html
Maybe I am wrong, but looking at the tsysteminfo does the value in
extradefines specify values that will be defined during compilation
(such as those given on that page)?
If the do then "sunos" has
fpc 3.2.3
The below prog prints 3 times: 11, -1 (signed values)
https://www.freepascal.org/docs-html/current/ref/refsu4.html#x26-250003.1.1
Free Pascal also supports the ByteBool, WordBool, LongBool and
QWordBool types. These are of type Byte, Word, Longint or Int64,
Besides the fact that
Enums must be ascending. Otherwise a compiler note will be issued... Or not.
Below prog gives
project1.lpr(4,32) Note: Values in enumeration types have to be ascending
But if the values are cast first, then no warning.
The 2nd line will print 255, 0,-2 => which is not ascending.
program
On 14/12/2023 21:33, Marco van de Voort via fpc-devel wrote:
Op 14-12-2023 om 21:27 schreef Martin Frb via fpc-devel:
I am actually pretty sure, on Linux, I can get what I want by doing
it in the "OnFork" event of TProcess.
But on Windows it is well hidden away in the "
On 14/12/2023 20:54, Marco van de Voort via fpc-devel wrote:
Op 14-12-2023 om 20:29 schreef Martin Frb via fpc-devel:
Op 14-12-2023 om 17:30 schreef Martin Frb via fpc-devel:
If I am right the TProcess currently does not allow redirection of
StdOut/In to/from a file (or other handle provided
On 14/12/2023 18:13, Marco van de Voort via fpc-devel wrote:
Op 14-12-2023 om 17:30 schreef Martin Frb via fpc-devel:
If I am right the TProcess currently does not allow redirection of
StdOut/In to/from a file (or other handle provided).
It does, if you need a runcommandloop like routine
On 14/12/2023 18:06, Michael Van Canneyt via fpc-devel wrote:
Actually, I already started an implementation of an extension half a
year ago.
Is there an accessible branch for that? (maybe in a fork?)
___
fpc-devel maillist -
If I am right the TProcess currently does not allow redirection of
StdOut/In to/from a file (or other handle provided).
If it does, and I have been missing the "how to", then please enlighten
me and disregard the remainder of the mail.
The code for setting up redirection to pipes (to be
On 09/12/2023 17:03, Martin Frb via fpc-devel wrote:
Anyway, I changed the make
make install INSTALL_PREFIX=/home/m/fpc/$INSTPATH/gw3 OPT="
-Clv16.0 " LLVM=1
Then next it fails, with the same error on
make clean
Yes, it tries to compile a file while doing "make
On 09/12/2023 10:50, Jonas Maebe via fpc-devel wrote:
On 07/12/2023 13:52, Martin Frb via fpc-devel wrote:
I also looked for msg2inc. And msg2inc was compiled before
Maybe check the timestamps of compiler/msg*.inc,
compiler/utils/msg2inc.pp and compiler/msg/errore.msg. Perhaps some of
those
On 07/12/2023 13:52, Martin Frb via fpc-devel wrote:
On 07/12/2023 12:19, Jonas Maebe via fpc-devel wrote:
On 2023-12-07 01:09, Martin Frb via fpc-devel wrote:
But I am getting
make[8]: '/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux' is up
to date.
make[8]: Leaving directory '/home
On 07/12/2023 12:19, Jonas Maebe via fpc-devel wrote:
On 2023-12-07 01:09, Martin Frb via fpc-devel wrote:
But I am getting
make[8]: '/home/m/fpc/rel_3.3.1/source/rtl/units/x86_64-linux' is up
to date.
make[8]: Leaving directory '/home/m/fpc/rel_3.3.1/source/rtl/linux'
as --64 -o
/home/m
I was trying to build an fpc for clang 16 (same commands worked on a
diff machine for clang 11)
I changed the version in the make line:
make all OPT=" " OPTNEW=" -Clv16.0 " FPCMAKEOPT=" -Clv16.0 " LLVM=1
I also tried version 16.0.6
fpc 49cb7b256476409924c581145a760b863b9e755d
(I had tried
On 06/12/2023 21:58, Martin Frb via fpc-devel wrote:
On 06/12/2023 21:05, Jonas Maebe via fpc-devel wrote:
On 06/12/2023 17:37, Martin Frb via fpc-devel wrote:
Not suer if the issue is within Fpc or clang...
Should this be reported against Fpc?
FPC defines the variables' debug info
On 06/12/2023 21:05, Jonas Maebe via fpc-devel wrote:
On 06/12/2023 17:37, Martin Frb via fpc-devel wrote:
Not suer if the issue is within Fpc or clang...
Should this be reported against Fpc?
FPC defines the variables' debug info at the start of the function and
defines their lifetime
Not suer if the issue is within Fpc or clang...
Should this be reported against Fpc?
- Fedora 33
- Fpc 3.3.1 from Sept 26th
- make all OPT=" " OPTNEW=" -Clv11.0 " FPCMAKEOPT=" -Clv11.0 " LLVM=1
- clang --version
clang version 11.0.0 (Fedora 11.0.0-3.fc33)
Target: x86_64-unknown-linux-gnu
On 09/11/2023 22:19, Marco van de Voort via fpc-devel wrote:
Op 9-11-2023 om 20:47 schreef Martin Frb via fpc-devel:
I saw that in some places (I think gtk2) "varargs" is used for open
arrray API calls.
Any reason that is not adapted for Windows (overloaded)?
It probably is ne
On 10/11/2023 10:49, Adriaan van Os via fpc-devel wrote:
Sorry, but I am looking for a diff for fpc bug #38492. Mantis says
"'Fixed in Revision: 38492" which looks like a mistake, as 38492 is
the bug number. Also gitlab reports fix #11ef1d17 which is instead a
register allocation fix.
Is the
I saw that in some places (I think gtk2) "varargs" is used for open
arrray API calls.
Any reason that is not adapted for Windows (overloaded)?
function wsprintfA(_para1:LPSTR; _para2:LPCSTR; const args:array of
const):longint; cdecl; external 'user32' name 'wsprintfA';
function
On 09/11/2023 14:19, Marco van de Voort via fpc-devel wrote:
Anyway, standard procedure in such cases is to move the pascallized
declaration to redef.inc and have a pointer value in the original
place. Which I just commited to GIT.
Thanks. Merge-able?
Fpc defines
function CreateConsoleScreenBuffer(dwDesiredAccess:DWORD;
dwShareMode:DWORD; var lpSecurityAttributes:SECURITY_ATTRIBUTES;
dwFlags:DWORD; lpScreenBufferData:LPVOID):HANDLE; external 'kernel32'
name 'CreateConsoleScreenBuffer';
`lpSecurityAttributes` is a `var` param in the above.
On 06/10/2023 15:11, Marco van de Voort via fpc-devel wrote:
Op 6-10-2023 om 14:28 schreef Martin Frb via fpc-devel:
What is the difference between those 3?
OPT= always to my best knowledge
NEWOPT is opt only for later cycles and the rest, iow not for the
first FPC bootstrap cycle
What is the difference between those 3?
I came across OPTNEW here https://wiki.freepascal.org/LLVM
But now I am trying to play with the rather old fpc build script for the
laz installer.
And it calls
%MAKEEXE% compiler_cycle PP=%RELEASE_PPC% >> %LOGFILE% 2>&1
%MAKEEXE% rtl_clean
I am getting the error in the subject
ececf26d872c9fdc0a315c6289df864f66a1f69a
make.exe all LINKSMART=1 CREATESMART=1 OPTIMIZE=1 OPT="-CX -gl -O4
-Ooregvar" FPC=C:\FPC\fpc_3.2.2\32\def\bin\i386-win32\fpc.exe
OPTNEW="-CX -gl -O4 -Ooregvar" FPMAKEOPT="-T 6"
While looking at
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/448#note_1540865966
DW_AT_declaration came up.
From the DWARF 5 spec
A debugging information entry that represents a non-defining or
otherwise 11 incomplete declaration of a program entity has a
DW_AT_declaration
On 14/08/2023 14:52, Michael Van Canneyt via fpc-devel wrote:
On Mon, 14 Aug 2023, Martin Frb via fpc-devel wrote:
Does "with" take the "address" of the value, and operate on that
address, even if the address of that value could change within the
"with&quo
In the below code, the array is resized (and more important relocated in
mem) inside the function "bar".
The commented line (without "with") works as expected.
The "with" line has a different behaviour. I guess it is by design. Just
wanted to confirm.
The version with "with" prints 12345
On 20/07/2023 19:24, Michael Van Canneyt via fpc-devel wrote:
It's IMO probably better to outright forbid passing open array by
reference.
printing length(a) after x:=Nil; gives 10, which is simply wrong.
The open array is not the same as the dyn array.
It is at any point just a slice of
For const param, it is well documented that the value (that includes the
variable that is passed) must not be changed.
But for "var param"?
Well maybe, but not explicit
https://www.freepascal.org/docs-html/ref/refsu68.html#x184-20800014.4.5
>> Open parameters can be passed by value, by
On 19/07/2023 10:22, Michael Van Canneyt via fpc-devel wrote:
The error is logical. What is not logical is that it pops up now.
By all logic, we should have seen this error pop up as early as 2016.
Why it pops up only now is a mystery that we need to solve...
I don't have all the details,
On 18/07/2023 22:56, Martin via fpc-devel wrote:
Using 33dba315366ec3002e062c3aa6dcb15b88356580 (3.3.1)
My fpc.cfg looks like this / any idea?:
Threading has been used before cthreads was initialized.
Make cthreads one of the first units in your uses clause.
tried
Currently the debugger can not show properties (even though it can call
functions).
DWARF does not know properties, but custom tags can be added. Joost
started this in the branch fork-gl/joost/dwarfproperties
https://gitlab.com/freepascal.org/fpc/source/-/tree/joost/dwarfproperties
Rebased
On 08/06/2023 19:59, Giuliano Colla via fpc-devel wrote:
Il 08/06/23 18:40, Martin Frb via fpc-devel ha scritto:
It seems that on Cocoa an exe is by default relocatable.
At least a basic test shows that dumping a stack at runtime for each
run (no new compile) gives new addresses.
Fpc 3.2.2
It seems that on Cocoa an exe is by default relocatable.
At least a basic test shows that dumping a stack at runtime for each run
(no new compile) gives new addresses.
Fpc 3.2.2
Is there a way to turn this off? (some flag to pass to the linker?)
___
On 28/03/2023 15:50, Martin Frb via fpc-devel wrote:
On 28/03/2023 15:03, Sven Barth via fpc-devel wrote:
Martin Frb via fpc-devel schrieb am
So., 26. März 2023, 16:50:
It also would fall short, if ever Fpc did what Delphi did:
{$ZEROBASEDSTRINGS }
Though, maybe that is a "
On 28/03/2023 15:03, Sven Barth via fpc-devel wrote:
Martin Frb via fpc-devel schrieb am
So., 26. März 2023, 16:50:
It also would fall short, if ever Fpc did what Delphi did:
{$ZEROBASEDSTRINGS }
Though, maybe that is a "wont ever happen".
FPC supports that direc
On 26/03/2023 16:50, Martin Frb via fpc-devel wrote:
On 26/03/2023 15:50, Florian Klämpfl via fpc-devel wrote:
What about using DW_TAG_string_type for this? IIRC, when I
implemented dwarf, it was not available/not supported, but fpdebug
can do they. I am not sure about the status of GDB about
On 27/03/2023 22:59, Sven Barth via fpc-devel wrote:
Am 26.03.2023 um 13:30 schrieb Martin Frb via fpc-devel:
TSome = class;
TSome = class(specialize GenLinkedList);
The correct way to declare a generic linked list using classes is the
following:
=== code begin ===
type
generic
On 26/03/2023 15:50, Florian Klämpfl via fpc-devel wrote:
Am 23.03.23 um 09:45 schrieb Martin Frb via fpc-devel:
It's a little hard to comment all at once, but at least I start with
one :)
4) "official" marker for string vs pchar vs array
What about using DW_TAG_s
3.2.3 and 3.3.1 on Win 64bit
Trying a generic linked list.
So the specialized class must have an entry for the "next" element. And
that entry is of the same type as the class itself.
Now at first, this seems to be not possible using generics, because
specialize does not allow to pass in the
After the brief exchange on
https://gitlab.com/freepascal.org/fpc/source/-/issues/40208
There are various considerations (ideas/requests) to hopefully help
improve debugging experience.
I have recently added 3 issues, but there is more. And I wanted to add a
bit of background here, since it
So it seems to be that topic
https://forum.lazarus.freepascal.org/index.php?topic=39416.0
>> Is and As operators require that the interface has a GUID defined
Only that in my case the compiler happily compile
(MyObjec as TCorbaWithoutGUID).foo;
Shouldn't that give an error?
While I haven't got a simple example, by this time I am sure the issue
is not in my code. (it's not online avail yet)
I have a class, with 2 corba interfaces
TIdeLocalsValue = class(TLocalsValue, TWatchAbleResultIntf,
TWatchAbleDataIntf)
...
end
If I get an interface using
(SomeVar as
On 03/03/2023 14:29, Sven Barth via fpc-devel wrote:
All identifiers must be known when declaring a generic. In this case
Trec1 is known thanks to the global type. Trec2 is not known (neither
in its parent (at declaration time TBase1) nor globally) , so that
will fail.
When you specialize
To me the below behaviour appears inconsistent.
But before I file a bug, I want to double check, if maybe this is
intention
Tested with 3.2.3 and 3.3.1
Apparently
- when the generic TGen is compiled, it does check if a type "TRec1" and
"TRec2" is in scope at all.
- it verifies that the
On 01/03/2023 14:22, J. Gareth Moreton via fpc-devel wrote:
On 01/03/2023 13:11, Martin Frb via fpc-devel wrote:
Hence testing back to 3.2.3 ( unfortunately 3.2.2 has a bug that
matters in this code)
Also, I didn't expect any huge diffs, just wanted to see if anything
can be noted at all
On 01/03/2023 12:25, J. Gareth Moreton via fpc-devel wrote:
My peephole optimisations mostly save only a handful of cycles each
time which probably won't add up to much for a relatively short test.
The most major optimisation I can think of, although I'm not quite
sure when it was merged, is
On 01/03/2023 11:55, Adriaan van Os via fpc-devel wrote:
That may have been "-Performance Matters- by Emery Berger". By I find
it a nonsense video.
Only that last year, I had some code where it happened to me. Some code
(that had no change in itself, other than a routine above it (which was
On 01/03/2023 11:47, Bart via fpc-devel wrote:
On Wed, Mar 1, 2023 at 11:33 AM Martin Frb via fpc-devel
wrote:
So for a while now fpc 3.3.1 receives new optimizations => which is
great / big fan of it.
And hence I thought, lets see how much of an impact they have. And in my
test, they
So for a while now fpc 3.3.1 receives new optimizations => which is
great / big fan of it.
And hence I thought, lets see how much of an impact they have. And in my
test, they had none :(
Wondering if any one else has measured them?
My tests:
Win-10 64 bit
3.3.1
I don't currently have many details. (The code in question has been
working on older 3.3.1, and still works on 3.2.3 and before)
I included various details, but in the end it may be a peephole issues
in "GetInterfaceByStr"
==> So probably skip ahead to the asm code below.
The code call a
On 21/12/2022 11:37, Marc Weustink via fpc-devel wrote:
On 20-12-2022 21:12, Sven Barth via fpc-devel wrote:
So the only logical solution is to stop the offending thread from
executing or not to have it call InitThread() while the
initialization section of the System unit is still running.
On 28/11/2022 16:37, Martin Frb via fpc-devel wrote:
"11.3μop cache"
Apart from the qop cache there is the normal loading into the cache.
I must admit I am not sure on the exact workings, but wasn't there
something like loading entire cachelines? If that is so (not sure),
then
On 28/11/2022 16:19, J. Gareth Moreton via fpc-devel wrote:
I admit I can be disorganised sometimes and lose documents, so I
apologise if you have sent them already and I mislaid them in my mess
of a directory tree. Believe me though, I want to swallow all of this
up if it means squeezing out
On 28/11/2022 14:32, J. Gareth Moreton via fpc-devel wrote:
On 28/11/2022 12:59, Martin Frb via fpc-devel wrote:
Well first of all, you didn't move the balign in front of .Lj732
I do move the alignment hints, but if the label becomes dead (due to
the zero-distance jump being 'collapsed
On 28/11/2022 07:22, J. Gareth Moreton via fpc-devel wrote:
...
testb %al,%al
je .Lj733
subb $1,%al
je .Lj734
jmp .Lj732
.balign 16,0x90
.Lj733:
...
jmp .Lj718
.balign 16,0x90
.Lj732:
movl $2019050530,%ecx
call
On 19/10/2022 22:56, Martin Frb via fpc-devel wrote:
On 19/10/2022 21:12, Pierre Muller via fpc-devel wrote:
Hi Martin,
could you tell me if
https://gitlab.com/freepascal.org/fpc/source/-/issues/39928#note_1140122898
fixes your troubles?
Thanks in advance,
It looks like the right
On 19/10/2022 21:12, Pierre Muller via fpc-devel wrote:
Hi Martin,
could you tell me if
https://gitlab.com/freepascal.org/fpc/source/-/issues/39928#note_1140122898
fixes your troubles?
Thanks in advance,
It looks like the right direction. But see my comment on the issue.
It is correct
Revision: 1b6982107f1ac4b4111e37be0a3649d155a2bc1e
Author: florian
Date: 10/10/2022 22:45:31
Message:
* TDebugInfoDwarf3.appenddef_object should not write an extra
finish_entry for objects and C++ classes
This adds extra DW_OP_... statements in 2 places
In
procedure addstringdef(const
On 18/09/2022 14:29, Bart via fpc-devel wrote:
I wonder anyway
TCustomSpinEditEx = class(specialize TSpinEditExBase)
But "SameValue" does not exist for int64 (or any int)?
So I assume the compiler converts the int to a float
(Note:
The base class can have a virtual abstract
On 18/09/2022 11:37, Bart via fpc-devel wrote:
Hi,
The following program will compile for Windows 32 and 64 bit.
It fails to compile for Linix 64 bit (and if I understand correctly,
also for MacOS 64 bit).
Just enable fpc_math_samevalue_bug
{$if FPC_FullVersion=30202}{$ifdef Win64}
On 15/09/2022 21:35, Sven Barth via fpc-devel wrote:
Am 15.09.2022 um 14:32 schrieb Martin Frb via fpc-devel:
https://gitlab.com/freepascal.org/fpc/source/-/issues/39904
On top of adding the functions in the interface to the dwarf info, it
would be great if the compiler could also add some
On 15/09/2022 16:17, Michael Van Canneyt via fpc-devel wrote:
On Thu, 15 Sep 2022, Martin Frb via fpc-devel wrote:
https://gitlab.com/freepascal.org/fpc/source/-/issues/39904
On top of adding the functions in the interface to the dwarf info, it
would be great if the compiler could also add
https://gitlab.com/freepascal.org/fpc/source/-/issues/39904
On top of adding the functions in the interface to the dwarf info, it
would be great if the compiler could also add some sort of link to the
underlaying TObject.
So the debugger could (if available) show the user the object/instance
On 17/08/2022 02:21, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
Recently I've made some optimisations centred around the SHR
instruction on x86, and there was one pair of instructions that caught
my attention:
movl (%rbx),%eax
shrl $24,%eax
Is it permissible to optimise this to
On 16/08/2022 09:37, Michael Van Canneyt via fpc-devel wrote:
On Tue, 16 Aug 2022, Juha Manninen via fpc-devel wrote:
And function GetEnumValue() is buggy.
It is not buggy. It does not support enumerateds with gaps, because
RTTI does not support enumerateds with gaps.
It never has.
...
On 11/08/2022 18:11, Juha Manninen via fpc-devel wrote:
The MaxValue is used in many places for enum and set properties while
GetEnumNameCount() is not used anywhere.
There are other similar bugs. At least these 2 in propedits.pp look fishy:
- procedure TSetPropertyEditor.GetProperties
On 11/08/2022 13:38, Juha Manninen via fpc-devel wrote:
// An empty string and the enum's unit name happen in gaps
// of a non-contiguous enum. Why the unit name? A bug in FPC code?
with GetTypeData(EnumType)^ do
for I := MinValue to MaxValue do begin
s :=
On 04/07/2022 21:11, Michael Van Canneyt via fpc-devel wrote:
On Mon, 4 Jul 2022, Joost van der Sluis via fpc-devel wrote:
Hi all,
I have a very small application, see below. One procedure is not
called at all.
But when I compile with
ppcx64 -XX -CX testcfi.pp
The
My 3.3.1 build is from the 27th June.
However the error did happened with the previous build too. (That is
according to error msg, I did not compare the trace).
During a build of the Lazarus IDE, ppu files from the previous build
still in place. Just a handful of source files changed.
There
In the below code specialization takes a boolean constant.
The compiler (kind of) allows expressions that can be evaluated at
compile time.
Of course
specialize TGen< 5>1 >;
does not work. The ">" can't be distinguished from the end of the param
list.
Not sure why
specialize TGen<
is it allowed to use the identifier "specialize" as constant (or type or
var)?
Because it compiles with 3.3.1. (the line that defines the constant).
But it seems it can't be used.
At least it fails in the below scenario, when trying to use as value.
program foo;
{$mode objfpc}{$H+}
const
https://docs.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-raiseexception
|void RaiseException( [in] DWORD dwExceptionCode, [in] DWORD
dwExceptionFlags, [in] DWORD nNumberOfArguments, [in] const ULONG_PTR
*lpArguments );|
In the below code some fields are 32bit
On 25/03/2022 20:25, Jonas Maebe via fpc-devel wrote:
On 24/03/2022 01:57, Martin Frb via fpc-devel wrote:
It appears with 3.2.2 the address of a global var in dwarf already
contains the relocation.
Since fpdebug, does not retrieve any relocation info from lldb, it
does not adjust any
It appears with 3.2.2 the address of a global var in dwarf already
contains the relocation.
Since fpdebug, does not retrieve any relocation info from lldb, it does
not adjust any addresses.
But with 3.3.1 it seems different.
https://forum.lazarus.freepascal.org/index.php?topic=58822.new#new
This must have been asked before, but I couldn't find any details.
My question is about having an untyped const param vs a normal typed param.
program Project1;{$mode objfpc}{$H+}
procedure Foo(P1: Integer; const P2); overload;
begin writeln('const ', P1); end;
procedure Foo(P1: Integer;
According to https://www.freepascal.org/docs-html/ref/refse53.html
the keyword "object" is allowed as a "type identifier" for identifiers
in the "template list" of a generic definition.
Yet, the below does not compile (tested with 3.2.0 / 3.2.2 / 3.2.3 and
3.3.1 from 2022-Feb-10)
program
On 16/02/2022 21:21, Dmitry Boyarintsev via fpc-devel wrote:
On Wed, Feb 16, 2022 at 3:17 PM Martin Frb via fpc-devel
wrote:
Anything similar on M1?
should it be ARM64 calling convention?
https://en.wikipedia.org/wiki/Calling_convention#ARM_(A64)
Possible. I have a bit of disassembly
Trying to get the IDE lldb based debugger to work on M1
But I don't have M1 myself, so ...
When
procedure fpc_Raiseexception (Obj : TObject; AnAddr : CodePointer;
AFrame : Pointer); compilerproc;
is entered, the IDE tries to get the arguments. In normal user installs
this code has no
Should the below then work? (It currently does)
Note, using "TBar = class end;" inside TFoo => does not work (expected).
It creates a type TFoo.TBar.
But the "type Abc = TBar" >imports< the outer forward declaration.
Btw, the compiler also does not care which of the 2 procedure
declarations
In the below code compiled with 3.2.3 (today and early Dec)
when the exception is reached the app exits.
There is no code from finally, nor from except block executed.
The "randomize" is just to put some code into each block. No special
meaning otherwise.
This issue is on Win64. (works for
On 12/01/2022 18:48, Sven Barth via fpc-devel wrote:
[2] From the users view "random", in that the user can not predict
all
the factors that will affect the selection.
Currently the user must be prepared for the latter.
No, it is deterministic, it's simply different from a
On 12/01/2022 17:31, Tomas Hajny via fpc-devel wrote:
On 2022-01-12 16:03, Martin Frb via fpc-devel wrote:
But, if any change to the code (not even necessarily a functional
change) would allow the compiler to do those calculations at compile
time, then the value changes. And the entire
On 12/01/2022 13:55, Tomas Hajny via fpc-devel wrote:
- The problem is *NOT* a native 64 bit "ppcx64.exe" ?
=> 64 bit compiled targets don't require "extended" from the ppc,
as they themself wont have support for it?
Wrong - applies only to the Win64 target, whereas e.g. 64-bit Linux
On 12/01/2022 11:51, Marco van de Voort via fpc-devel wrote:
On 12-1-2022 11:38, Ben Grasset via fpc-devel wrote:
If it's actually now somehow the case that an offer to provide Win64
builds would be refused though, I guess maybe I'll look into hosting
them myself somewhere else? Although
On 09/01/2022 19:04, Florian Klämpfl via fpc-devel wrote:
Am 09.01.2022 um 18:59 schrieb Martin Frb via fpc-devel
:
Just thought this may be interesting.
Though the results are for "eyeballing" at best -- see the video linked in
Jonas' recent mail:
https://lists.freepascal.org/pip
1 - 100 of 348 matches
Mail list logo
