On 06/06/2024 16:50, Martin Frb via fpc-devel wrote:
On 02/06/2024 22:28, Florian Klämpfl via fpc-devel wrote:
To get finally forward with the 3.2.4 release, fixes will be frozen
by 9th June, so if there are some last second cherry picks needed,
now it’s time to speak up :)
Has the line info
On 02/06/2024 22:28, Florian Klämpfl via fpc-devel wrote:
To get finally forward with the 3.2.4 release, fixes will be frozen by 9th
June, so if there are some last second cherry picks needed, now it’s time to
speak up :)
Has the line info field for Dwarf 4 been merged?
On 02/06/2024 21:06, J. Gareth Moreton via fpc-devel wrote:
I admit I'm not overly sure how to handle Thaddy sometimes:
"They fixed it in the wrong way. It is fixed in a way to solve a
single - rare - problem by an OP that seems to have more infuence than
me and the fixer(s) would not
While not sure how 3.2.4 preparation are going, nor what is still
outstanding for merging, I just wanted to quickly check if the following
is know (and hopefully making the list)
https://forum.lazarus.freepascal.org/index.php/topic,67448.0.html
From what I can tell
- present in today's 3.2.3
-
On 23/05/2024 22:55, Florian Klämpfl via fpc-devel wrote:
On 23.05.24 14:51, Martin Frb via fpc-devel wrote:
If I am not missing any detail
Using -gw 4 it seems fpc writes the same header for line info as it
does for dwarf 3.
However, when the line info version is set to 4 (at least
If I am not missing any detail
Using -gw 4 it seems fpc writes the same header for line info as it does
for dwarf 3.
However, when the line info version is set to 4 (at least if all units
are dwarf 4 / if some are dwarf 3 this may not be the case)
Dwarf 4 has a new field in the header,
Anyone any feedback, please?
Or, who would be knowledgeable, and might at least tell me when there
might be time, if too busy right now?
On 17/05/2024 13:49, Martin Frb wrote:
On 09/05/2024 19:53, Martin Frb via fpc-devel wrote:
It's now an issue for the Dwarf standard.
https
On 09/05/2024 19:53, Martin Frb via fpc-devel wrote:
It's now an issue for the Dwarf standard.
https://dwarfstd.org/issues/240507.1.html
Looking at the time other proposals have taken, I think it is reasonable
to implement properties as custom extension now. And then later make any
The below fails to compile.
However "b" is a class var. The fact that it is reached via a normal
field, does not change that. The address/value of TBar.f.b can be known
without on instance of TBar required.
Mind, this is a theoretical question, I don't actually need it, just
came across the
It's now an issue for the Dwarf standard.
https://dwarfstd.org/issues/240507.1.html
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Maybe of interest?
The include file {$i ascdef.inc} is used from unit Windows with
{$calling stdcall}
in effect.
Most functions in it therefore don't have "stdcall". But some do. Is
that known/wanted/...?
Similar in some other includes.
___
On 03/05/2024 14:17, Sven Barth via fpc-devel wrote:
Martin Frb via fpc-devel schrieb am
Fr., 3. Mai 2024, 12:13:
In case it goes ahead, I am trying to thing of what would be
needed
Can anyone think of any feature for Pascal properties that is not
covered by the below
On 02/05/2024 20:59, Jonas Maebe via fpc-devel wrote:
---
I don't have background on the Apple properties.
It's not Apple, but Objective-C.
Does FPC create such Objective-C code / properties?
If yes, how does it decide on how to translate "property Foo..."?
In case it goes ahead, I am trying to thing of what would be needed
Can anyone think of any feature for Pascal properties that is not
covered by the below?
# Proposal to implement "properties" for Pascal
## Background
Pascal has a property construct, that allows a "variable like"
On 02/05/2024 20:59, Jonas Maebe via fpc-devel wrote:
---
I don't have background on the Apple properties.
It's not Apple, but Objective-C.
property goes from the member to the property strikes me as odd.
(first example of dwarf)
It indicates, that the property is only meant
https://github.com/llvm/llvm-project/blob/main/llvm/docs/SourceLevelDebugging.rst#debugging-information-format-1
Objective C properties exist separately from class members. A
property can be
defined only by "setter" and "getter" selectors, and be calculated
anew on each
access. Or a
On 27/04/2024 22:10, Jonas Maebe via fpc-devel wrote:
On 27/04/2024 21:40, Martin Frb via fpc-devel wrote:
First, telling the asm to store ".l99 - .ldebuginfo" or telling the
asm to store 733 (having done the math already) will result in the
same dwarf info.
Of course this
On 27/04/2024 20:29, Jonas Maebe via fpc-devel wrote:
On 27/04/2024 17:18, Martin Frb via fpc-devel wrote:
One of the posts also brings up the idea of avoiding labels (in asm),
and keep track of locations by counting the bytes in the generated
dwarf as part of the compilers work (IMHO
On 27/04/2024 17:05, Martin Frb via fpc-devel wrote:
On 27/04/2024 15:24, Jonas Maebe via fpc-devel wrote:
On 27/04/2024 13:45, Martin Frb via fpc-devel wrote:
Ok, I would like to start another attempt to support properties when
using fpdebug as debugger.
I would recommend asking guidance
On 27/04/2024 15:24, Jonas Maebe via fpc-devel wrote:
On 27/04/2024 13:45, Martin Frb via fpc-devel wrote:
Ok, I would like to start another attempt to support properties when
using fpdebug as debugger.
I would recommend asking guidance on the DWARF list (dwarf-discuss).
Maybe
am not familiar with
the FPC codebase).
I do now get some guesses as to why...
-
But anyway, I started my own attempt based on that.
https://gitlab.com/martin_frb/fpc-src/-/compare/main...martin-dwarf-properties?from_project_id=28644964=false
The first problem is getting labels
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 18:41, Martin Frb via fpc-devel wrote:
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"?
Actually my previous example was not even the generic case.
Passing any variable that is
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
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.
___
fpc-devel maillist -
en't in the DWARF.
Well, the class is copied into each unit (on Linux there is a cross
compile-units reference).
The copies are without entry_pc, but there is on pointer to were to find
the original info (which may not be present, if that unit did not have
debug info)
=
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.
Ok, I don't know too much about the whole initialization
But on the off chance of triggering some ideas, I throw in a couple of
my thoughts
On 19/12/2022 07:42, Sven Barth wrote:
Am 07.07.2018 um 15:04 schrieb Martin:
So (guessing) the original issue may be due to the debugger
On 20/12/2022 15:08, Martin wrote:
Ok, I don't know too much about the whole initialization
But on the off chance of triggering some ideas, I throw in a couple of
my thoughts
On 19/12/2022 07:42, Sven Barth wrote:
This is likely to be the cause, cause the EXEC_TLS_CALLBACK
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}
1 - 100 of 1522 matches
Mail list logo