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
Hello,
You have not read closely what I wrote before:
"When compiling RTL you should disable reading of options from fpc.cfg using
the -n switch.
When compiling the system unit use the -Us switch.
Additionally specify only CPU/Target and optimization options -O.
No other options are required
Hello,
I've take a look at you RTL compile script and found the mess with the compiler
options.
When compiling RTL you should disable reading of options from fpc.cfg using the
-n switch.
When compiling the system unit use the -Us switch.
Additionally specify only CPU/Target and optimization
Hello,
Your test program runs fine when compiled with FPC 3.2.0 using the official RTL
compiled with -O2. No memory leak.
I suppose the issue is caused by your modifications to RTL. -O2 (regvars) just triggers the problem in the modified RTL
code which is hidden when regvars are disabled.
You
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.
15 matches
Mail list logo
