On 12.02.2023 23:04, J. Gareth Moreton via fpc-devel wrote:
Yeah, of course, since LongInt($8001), before typecasting to HKEY, is
specifically a signed constant. So obvious!!
Declarations like this have been made on purpose:
HKEY_CURRENT_USER = HKEY(longint($8001));
On Win64
On 13.12.2021 4:57, Karoly Balogh via fpc-devel wrote:
Should be fixed now. The AVs have occurred only when targeting the AVX FPU.
Yuriy, your fix seems to break m68k, in particular m68k runs into that
newly added IE:
~External command
On 12.12.2021 16:24, Marco van de Voort via fpc-devel wrote:
On 12-12-2021 15:19, Florian Klämpfl via fpc-devel wrote:
What -Cp/-Cf option do you use?
To compile FPC:
set CPUOPTS=-O2 -Opcoreavx -Cpcoreavx
set CPUOPTS64=-Cfavx
I didn't enter those in Lazarus I think, so that should be
On 11.12.2021 22:31, Marco van de Voort via fpc-devel wrote:
FPC trunk building lazarus trunk fails with compiler AV ?
An old ghost seems to have resurfaced. I didn't build a development lazarus for a while (I used a stable one for work),
but at least 1-2 weeks I have this problem:
(3104)
On 16.10.2021 21:45, J. Gareth Moreton via fpc-devel wrote:
I figured that virtual methods would be no-go and that this would only apply to static methods. It seems a shame to
dismiss it completely though because there's a huge number of procedures that compile to the same code, especially
On 04.10.2021 20:24, J. Gareth Moreton via fpc-devel wrote:
I have a suspicion as to what it might be. Can you produce the faulty assembly language with DEBUG_AOPTCPU so it shows
the comments? Does it say "Mov2Nop 3" where the missing instruction lies?
I've already fixed this bug in trunk
On 04.10.2021 4:44, Martin Frb via fpc-devel wrote:
Update to my original mail:
https://lists.freepascal.org/pipermail/fpc-devel/2021-June/043884.html
I found the needle in the haystack.
It appears fixed in current (2 day old) fixes 3.3.1. / I have not tested trunk.
-
On August 23, 2021 19:41:41 Bart via fpc-devel
wrote:
On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel
wrote:
Just move common.dll from SysWOW64 to system32. The file is placed wrongly
by some installer.
If I understand Tomas correctly then that would not make any
difference
On August 23, 2021 16:17:03 Bart via fpc-devel
wrote:
On Mon, Aug 23, 2021 at 2:57 PM Tomas Hajny via fpc-devel
wrote:
The problem is that MS Windows employs a special trickery by which the
path to c:\windows\system32 (almost surely in your PATH) translates to
c:\windows\SysWOW64
On 24.05.2021 23:16, Jonas Maebe via fpc-devel wrote:
On 24/05/2021 12:18, Yuriy Sydorov via fpc-devel wrote:
You can't first pass the -Mdelphi switch and then override it with
-Mfpc. -Mdelphi implicitly enables lot of other compiler options which
are not reverted by -Mfpc.
That feels like
is the intended
state for compiling the RTL.
RTL must be compiled in the FPC mode. No other modes must be specified in the command line or fpc.cfg. You can't first
pass the -Mdelphi switch and then override it with -Mfpc. -Mdelphi implicitly enables lot of other compiler options
which are not re
options -O.
No other options are required for Windows RTL.
When RTL is properly compiled, even with -O2, your test program works without
memory leaks.
Yuriy Sydorov,
j...@cp-lab.com
On 20.05.2021 15:43, NetSpirit via fpc-devel wrote:
RTL not modified. Just recompilation of 'sysinitpas.pp' unit
it can be fixed.
Yuriy Sydorov,
j...@cp-lab.com
On 20.05.2021 11:07, NetSpirit via fpc-devel wrote:
Answer for my previous message
(https://lists.freepascal.org/pipermail/fpc-devel/2021-January/043512.html).
Memory leak happens when unit 'rtl\win32\sysinitpas.pp' compiled with
"-O2"
Hi,
On 26.11.2020 17:34, J. Gareth Moreton via fpc-devel wrote:
Hi everyone,
So a couple of people have reported that -O2 sometimes produces bad code under x86_64. So far it seems isolated to that
CPU.
https://bugs.freepascal.org/view.php?id=38129
After my own investigations with the
On 19.08.2020 21:23, Martin Frb via fpc-devel wrote:
On 22/06/2020 18:36, Jonas Maebe wrote:
On 21/06/2020 22:07, Yuriy Sydorov wrote:
It may also be also broken with FPC's code generator, but simply not get
detected at compile time.
Fixed.
Thanks!
Just tested with 3.3.1 from 17.08.2020
On 01.08.2020 21:01, Yuriy Sydorov wrote:
On 01.08.2020 14:59, Schindler Karl-Michael wrote:
Am 01.08.2020 um 12:00 schrieb fpc-devel-requ...@lists.freepascal.org:
Message: 1
Date: Sat, 1 Aug 2020 02:20:49 +0300
From: "Dimitrios Chr. Ioannidis"
To: FPC developers' list
Subject:
On 01.08.2020 14:59, Schindler Karl-Michael wrote:
Am 01.08.2020 um 12:00 schrieb fpc-devel-requ...@lists.freepascal.org:
Message: 1
Date: Sat, 1 Aug 2020 02:20:49 +0300
From: "Dimitrios Chr. Ioannidis"
To: FPC developers' list
Subject: [fpc-devel] FPC trunk embedded avr build broken
On 21.06.2020 0:34, Jonas Maebe wrote:
On 20/06/2020 20:50, Yuriy Sydorov wrote:
On 20.06.2020 16:17, Florian Klämpfl wrote:
Am 20.06.20 um 15:04 schrieb Jonas Maebe:
On 20/06/2020 14:59, Yuriy Sydorov wrote:
Maybe implement this in a clean way by adding a new generic
optimization
On June 21, 2020 00:34:01 Jonas Maebe wrote:
On 20/06/2020 20:50, Yuriy Sydorov wrote:
On 20.06.2020 16:17, Florian Klämpfl wrote:
Am 20.06.20 um 15:04 schrieb Jonas Maebe:
On 20/06/2020 14:59, Yuriy Sydorov wrote:
Maybe implement this in a clean way by adding a new generic
optimization
On June 20, 2020 23:22:13 Florian Klämpfl wrote:
Am 20.06.20 um 22:02 schrieb Karoly Balogh (Charlie/SGR):
Hi,
On Sat, 20 Jun 2020, Yuriy Sydorov wrote:
I've added the generic cs_opt_unused_para optimization option.
In future, if needed, more fine-grained related options can be introduced
On 20.06.2020 16:17, Florian Klämpfl wrote:
Am 20.06.20 um 15:04 schrieb Jonas Maebe:
On 20/06/2020 14:59, Yuriy Sydorov wrote:
Maybe implement this in a clean way by adding a new generic optimization
cs_opt_hiddenpara?
Maybe cs_opt_unusedpara. It doesn't have to be limited to hidden
On 20.06.2020 15:49, Jonas Maebe wrote:
On 20/06/2020 14:31, Yuriy Sydorov wrote:
On 20.06.2020 14:38, Jonas Maebe wrote:
On 20/06/2020 13:15, Yuriy Sydorov wrote:
On 20.06.2020 2:04, Martin wrote:
I just updated to fpc trunk 45658
It seems sometime in the last 3 or 4 month a change
On 20.06.2020 14:38, Jonas Maebe wrote:
On 20/06/2020 13:15, Yuriy Sydorov wrote:
On 20.06.2020 2:04, Martin wrote:
I just updated to fpc trunk 45658
It seems sometime in the last 3 or 4 month a change was made that
leads to "parentfp" being optimized away.
Even with -O- or -O1 (man
On 20.06.2020 2:04, Martin wrote:
I just updated to fpc trunk 45658
It seems sometime in the last 3 or 4 month a change was made that leads to
"parentfp" being optimized away.
Even with -O- or -O1 (many users do O1 for debugging)
I've turned off optimization of parentfp when -O- in r45661.
On 29.05.2020 22:36, Sven Barth via fpc-devel wrote:
Am 27.05.2020 um 00:41 schrieb Yuriy Sydorov:
On 27.05.2020 1:01, Joost van der Sluis wrote:
Op 26-05-2020 om 23:36 schreef Yuriy Sydorov:
Does it happen with the fpc trunk?
If yes, what revision do you use? It looks like an issue with my
On 27.05.2020 1:01, Joost van der Sluis wrote:
Op 26-05-2020 om 23:36 schreef Yuriy Sydorov:
Does it happen with the fpc trunk?
If yes, what revision do you use? It looks like an issue with my initial implementation of the $parentfp parameter
optimization. "$fin$0037" is a
On 26.05.2020 22:41, Joost van der Sluis wrote:
I have something strange.
I have a generic function defined as follows:
generic function TJSONRttiStreamClass.CreateObjectFromJSONStringstring = ''): T;
begin
Result := nil;
end;
When I call it, like this:
LaunchRequest :=
On 23.04.2020 23:55, Martin wrote:
I tried to build a 32bit FPC 3.2 (trunk / today svn)
cross compile targe win-64
with the following opitons
OPT="-CX -gl -O4 -Or"
The latest FPC trunk builds fine for me with your options.
Both cross-compiling to win64 and native win64 build.
Check if the
On 25.01.2020 11:59, Adriaan van Os wrote:
Any news on the 64-bit compiler for Android ? What is the current status ?
Support for aarch64-android and x86_64-android targets are present in FPC 3.2 and trunk. The support is stable, on par
with 32-bit android targets.
Yuriy.
On 07.03.2019 18:38, Bart wrote:
On Wed, Mar 6, 2019 at 10:09 PM Yuriy Sydorov wrote:
If you declare a function result as utf8string instead of string (ansistring)
then automatic conversion will be
performed when you assign the result of the function to a variable of type
string (ansistring
On 06.03.2019 22:21, Bart wrote:
Using UTF8String in TRegistry instead of String forces users to
consider the fact that returned strings are Utf8Encoded now always,
even if they (probably most of them) do not need that because what
they retrieve from and put in the registry fits into their
On 03.03.2019 17:45, Bart wrote:
On Sun, Mar 3, 2019 at 11:17 AM Yuriy Sydorov wrote:
This is good if you assign the result of ReadString() to a regular ansistring
var. But if you assign it to a
utf8string,unicodestring,widestring var - it will not return correct result for
chars
On 02.03.2019 18:53, Bart wrote:
On Sat, Mar 2, 2019 at 3:48 PM Joost van der Sluis wrote:
The utf8encode should go, just like the utf8decode's that we fixed already.
Shall I post a patch in the bugtracker?
If so: instead of
SomeAnsiString := UTf8Encode(SomeUnicodeString) do I make it an
On 25.02.2019 20:03, Bart wrote:
On Lazarus, this no problem, since by default all strings are UTF8
encoded, so all conversions are lossless.
In a plain fpc program though on Windows, default encoding is the
current codepage (cp1252 in my case) and information will get lost
when you process the
On 13.02.2019 11:40, LacaK wrote:
and in code I use for example:
MS := TStaticMemoryStream.Create;
MS.SetPointer(buffer, bufferLen);
MS.Position := 0;
Bitmap.LoadFromStream(MS);
MS.Free;
Btw, you can omit "MS.Position := 0;", since it is already zero for a new
On 12/16/2018 1:01 PM, Nikolai Zhubr wrote:
And, I still see tons of "ARM BLX instruction ..." warnings from ld of this
kind:
C:\FPC\3.0.4\bin\i386-Win32\arm-linux-ld.exe: arm\units\arm-linux\rautils.o: warning: ARM BLX instruction targets ARM
function
On 7/4/2018 12:09 AM, Florian Klämpfl wrote:
Am 03.07.2018 um 22:57 schrieb Ondrej Pokorny:
Probably I am the only one who thinks that the code below is ridiculous...
procedure TExternalAssemblerOutputFile.AsmWriteFiltered(p: pchar; len:
longint);
var
s: ansistring;
On 6/4/2018 2:51 PM, Adriaan van Os wrote:
Yuriy Sydorov wrote:
No special version is needed, use 3.0.4 release sources or trunk sources.
arm64 and x86_64 are not supported yet for android. I plan to add support for
these CPUs later.
Thanks, armv8 is required for Google Play from August 2019
On 6/4/2018 1:48 PM, Adriaan van Os wrote:
Yuriy Sydorov wrote:
The android target was merged to the main FPC sources years ago. Use FPC 3.0.4 sources or trunk to build a
crosscompiler for arm-android.
3.0.4 or the special 3.0.3 version ? Does this support armv8 ? ppca64 (3.0.3)
-i doesn't
On 5/30/2018 4:41 PM, Adriaan van Os wrote:
In the past - which was 2013, time flies by - I built an FPC cross-compiler on Mac OS X from the FPC targetandroid
branch sources. Together with Android binutils (and a linker patch) this worked well to build for Android on Mac OS X.
As far as I
40 matches
Mail list logo
