Re: [fpc-devel] Insufficient Dwarf info for Interfaces

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

Re: [fpc-devel] Insufficient Dwarf info for Interfaces

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

[fpc-devel] Insufficient Dwarf info for Interfaces

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

Re: [fpc-devel] Question about memory alignment (again!)

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

Re: [fpc-devel] Gaps in a non-contiguous enum

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. ...  

Re: [fpc-devel] Gaps in a non-contiguous enum

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

Re: [fpc-devel] Gaps in a non-contiguous enum

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 :=

Re: [fpc-devel] Smart-linking on linux/x86-64

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

[fpc-devel] 3.3.1 Access violation during compile

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

[fpc-devel] constant evaluation in generics params

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< 

[fpc-devel] const specialize = 1;

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

[fpc-devel] definition of "THREADNAME_INFO = record" IN procedure RaiseMSVCExceptionMethod in rtl\win\systhrd.inc

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

Re: [fpc-devel] MacOS/dwarf: Was there any change to how/when relocation info is included.

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

[fpc-devel] MacOS/dwarf: Was there any change to how/when relocation info is included.

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

[fpc-devel] overloaded functions - order of resolving ?

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;

[fpc-devel] generics with type-identifier "object" - documented yes, but ...?

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

Re: [fpc-devel] register calling convention for Apple M1 ?

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

[fpc-devel] register calling convention for Apple M1 ?

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

[fpc-devel] bug or feature - more

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

[fpc-devel] Issue 3.2.3 (ok in 3.3.1) Win64 "raise exception" does not go to "except"

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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

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

Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC

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

Re: [fpc-devel] @Gareth - Feedback on optimizations

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

[fpc-devel] @Gareth - Feedback on optimizations

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/pipermail/fpc-devel/2022-January/044336.html I run my FpDebug test case with 3.2.3 and 3.3.1 (both early Dec) The test runs about

Re: [fpc-devel] Double-checking an optimisation

On 09/01/2022 04:53, J. Gareth Moreton via fpc-devel wrote: On 09/01/2022 01:47, Martin Frb via fpc-devel wrote: I take it, it also is one (or two?) bytes longer? If that is in a loop, which otherwise is exactly within a 32 byte aligned block, then that could cause a slow down too

Re: [fpc-devel] Double-checking an optimisation

On 09/01/2022 01:37, J. Gareth Moreton via fpc-devel wrote: Hi everyone, So a merge request of mine was just approved that allows the peephole optimizer access to more registers when it needs one for temporary storage.  It allows it to make an optimisation on x86_64-win64 that wasn't

Re: [fpc-devel] Attn: J. Gareth // 3.3.1 opt = slower // Fwd: [Lazarus] Faster than popcnt

On 04/01/2022 18:43, Jonas Maebe via fpc-devel wrote: On 03/01/2022 12:54, Martin Frb via fpc-devel wrote: not sure if this is of interest to you, but I see you do a lot on the optimizer It's very likely unrelated to anything the optimiser does or does not do, and more regarding random

Re: [fpc-devel] Attn: J. Gareth // 3.3.1 opt = slower // Fwd: [Lazarus] Faster than popcnt

@Marco: havent played with popcnt => it could benefit from the "const to var" too. So I played around a bit... Of course, all this is intel only 1) var   Mask8, Mask1: qword;   Mask8 := EIGHTYMASK;   Mask1 := ONEMASK; And the constant no longer is assigned inside the loop. Also

Re: [fpc-devel] Attn: J. Gareth // 3.3.1 opt = slower // Fwd: [Lazarus] Faster than popcnt

On 04/01/2022 10:31, Marco van de Voort via fpc-devel wrote: Weird as mine is inlined with -Cpcoreavx -O4, with no special handling for 0. But that does put some things on shaky ground. Maybe zero the result before hand? Same here. About

[fpc-devel] Attn: J. Gareth // 3.3.1 opt = slower // Fwd: [Lazarus] Faster than popcnt

   pop 484 pop 484   pop 500 add 594   add 422 add 578   add 438 add 578   add 437 add 594   add 453// // (C) 2021 Martin Friebe and Marco van de Voort. // attempt to accelerate utf8lengthfast which is a length(s) in utf8 codepoints without integrity checking // //

Re: [fpc-devel] Lazarus server back online

On 31/12/2021 15:00, Werner Pamler via fpc-devel wrote: https://forum.lazarus.freepascal.org/index.php/topic,57621.msg428799.html#msg428799 --> the issue occured already on Dec 24. https://forum.lazarus.freepascal.org/index.php/topic,57611.msg428693.html#msg428693 --> the issue did not yet

Re: [fpc-devel] Lazarus server back online

On 31/12/2021 13:35, Bart via fpc-devel wrote: On Fri, Dec 31, 2021 at 8:49 AM Marc Weustink via fpc-devel wrote: Somebody on the forum said it happened before the server upgrade. It may well be the case. Old posts like

Re: [fpc-devel] fpc bug with M1

On 30/12/2021 21:07, Jonas Maebe via fpc-devel wrote: On 30/12/2021 21:03, Florian Klämpfl via fpc-devel wrote: Yes, but the question is: if we load a shortint into a register, do we need to sign extend it to 32/64 bit or not? I tend more and more to say that we shouldn’t require this.

Re: [fpc-devel] fpc bug with M1

On 30/12/2021 20:57, Jonas Maebe via fpc-devel wrote: On 30/12/2021 20:55, Martin Frb via fpc-devel wrote: On 30/12/2021 20:46, Jonas Maebe via fpc-devel wrote: On 30/12/2021 18:06, Florian Klämpfl via fpc-devel wrote: Ah yes, or like this. Nevertheless, the question is whether the ldrsb w0

Re: [fpc-devel] fpc bug with M1

On 30/12/2021 20:46, Jonas Maebe via fpc-devel wrote: On 30/12/2021 18:06, Florian Klämpfl via fpc-devel wrote: Ah yes, or like this. Nevertheless, the question is whether the ldrsb w0,[x0] is correct or not. Yes, I was unclear: with the "I don't know/remember where this is done" I meant

Re: [fpc-devel] fpc bug with M1

On 30/12/2021 17:16, Florian Klämpfl via fpc-devel wrote: Am 30.12.21 um 14:52 schrieb Jonas Maebe via fpc-devel: On 29/12/2021 00:48, Martin Frb via fpc-devel wrote: I don't have an M1 myself, but according to the data from the thread on the lazarus mail list, there is a bug in the 3.3.1 asm

[fpc-devel] fpc bug with M1

- Subject: [Lazarus] fpc bug with M1 [[was: Re: UTF8LengthFast returning incorrect results on AARCH64 (MacOS)]] Date: Tue, 28 Dec 2021 22:47:53 +0100 From: Martin Frb via lazarus Reply-To: Lazarus mailing list To: laza...@lists.lazarus-ide.org CC: Martin Frb # [43] R

Re: [fpc-devel] Functors

On 27/12/2021 00:18, bla...@blaise.ru wrote: On 27.12.2021 0:57, Martin Frb via fpc-devel wrote: writeln( aC(33) ); aC('hello'); the above examples are probably intended to show the syntax. But not indented to show any useful application? The test you quoted demonstrates what

Re: [fpc-devel] Functors

On 26/12/2021 02:16, Blaise--- via fpc-devel wrote: I propose that the support for https://en.wikipedia.org/wiki/Function_object be added to the FPC. ... begin aC := C.Create; writeln( aC(33) ); aC('hello'); I might be barging in a bit late. But (within the given set that we have

Re: [fpc-devel] Overlapping addresses between 2 procedures in dwarf info / 3.2.0

On 25/12/2021 14:44, Martin Frb via fpc-devel wrote: I am looking at some oddity I found following up https://forum.lazarus.freepascal.org/index.php/topic,57568.0.html Unfortunately, I have no code yet to reproduce it. Reproduced https://gitlab.com/freepascal.org/fpc/source/-/issues/39499

[fpc-devel] Overlapping addresses between 2 procedures in dwarf info / 3.2.0

I am looking at some oddity I found following up https://forum.lazarus.freepascal.org/index.php/topic,57568.0.html Unfortunately, I have no code yet to reproduce it. I have looked at the generated debug info, as given by objdump. file format pei-x86-64   Compilation Unit @ offset 0x0:   

Re: [fpc-devel] Minor doc error about "const param"

On 24/12/2021 18:07, Bart via fpc-devel wrote: On Fri, Dec 24, 2021 at 12:00 PM Adriaan van Os via fpc-devel wrote: Neither would the compiler allow (I hope) the const parameter to be passed as a var parameter. It does not: {$mode objfpc} {$h+} procedure foo(var x: integer); begin end;

Re: [fpc-devel] Minor doc error about "const param"

On 20/12/2021 12:29, Michael Van Canneyt wrote: On Mon, 20 Dec 2021, Martin Frb via fpc-devel wrote: Actually an commission, but an important one. https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4 > Specifying a parameter as Constant is giving the compi

[fpc-devel] Minor doc error about "const param"

Actually an commission, but an important one. https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4 > Specifying a parameter as Constant is giving the compiler a hint that the contents of the parameter will not be changed by the called routine. "by the called

[fpc-devel] Error: Internal error 200602035

I just got: fpdebugdebugger.pas(4322,1) Error: Internal error 200602035 Even on a clean build. (fpc 3.2.3, updated yesterday) I am not able to create a small example, but I saved the state of my lazarus dir to https://gitlab.com/martin_frb/lazarus/-/commits/fpc-err-internal-200602035 I hope

[fpc-devel] Bug? "overload" between class.method and plain procedure ?

Should overload work for the following? Upon seeing the method being overloaded, if (in the class hierarchy) no method  with matching signature is found, should procedures outside the class be searched? > project1.lpr(19,8) Error: Incompatible type for arg no. 1: Got "ShortInt", expected

[fpc-devel] Design ideas ... [[Re: Attn: Sven Can not use "specialize" to resolve forward declaration]]

The below might read as if it belongs on the Lazarus list. But this is not about Lazarus. This is about a general design idea (pro and con), and the possibilities the language provides. The example(s) just happen to be from Lazarus. On 09/12/2021 07:59, Sven Barth via fpc-devel wrote: For

[fpc-devel] Attn: Sven Can not use "specialize" to resolve forward declaration

https://gitlab.com/freepascal.org/fpc/source/-/issues/39459 You wrote >> No, this can not and this will never work. When a generic parameter has a constraint that constraint /must/ be adhered to and a forward declaration is /not/ a valid type for such a constraint (except for *class* /

Re: [fpc-devel] Building 3.3.1 make fails for Win 32

noted I have the --jobs  set to more than 1. On windows, every once in a 100 times that leads to random fails. On 26/11/2021 11:39, Martin Frb via fpc-devel wrote: Start compiler 3.2.2 make.exe  all LINKSMART=1  CREATESMART=1  OPTIMIZE=1  OPT="" FPC=C:\FPC\fpc_3.2.2\32\gw\bin\

[fpc-devel] Building 3.3.1 make fails for Win 32

Start compiler 3.2.2 make.exe  all LINKSMART=1  CREATESMART=1  OPTIMIZE=1  OPT="" FPC=C:\FPC\fpc_3.2.2\32\gw\bin\i386-win32\fpc.exe make.exe[4]: Leaving directory `c:/FPC/fpc_3.3.1/source/compiler' make.exe[3]: Leaving directory `c:/FPC/fpc_3.3.1/source/compiler'

[fpc-devel] Is this a bug? with A,B do overloaded_in_A_and_B

From the doc https://www.freepascal.org/docs-html/current/ref/refsu62.html#x172-19600013.2.8 any variable reference, or method reference is checked to see if it is a field or method of the record or object or class In the below code both objects have a "procedure def;", but they differ in

[fpc-devel] DWARF info may be incorrect for location-expression, when value is in register

Could anyone from the team comment on the following issue please? https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/28 It seems with -O2 FPC may set the location of a variable to a register (which is correct). But it then attempts    DW_OP_push_object_address, DW_OP_deref

Re: [fpc-devel] DWARF info may be incorrect for location-expression, when value is in register

On 23/10/2021 14:04, Martin via fpc-devel wrote: Could anyone from the team comment on the following issue please? https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/28 It seems with -O2 FPC may set the location of a variable to a register (which is correct

[fpc-devel] DWARF info may be incorrect for location-expression, when value is in register

Could anyone from the team comment on the following issue please? https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/28 It seems with -O2 FPC may set the location of a variable to a register (which is correct). But it then attempts    DW_OP_push_object_address, DW_OP_deref

Re: [fpc-devel] Anyone an idea were/how to look for the missing merge in 3.2.0 [[peephole / fixed]]

On 04/10/2021 20:36, Yuriy Sydorov via fpc-devel wrote: 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

Re: [fpc-devel] Anyone an idea were/how to look for the missing merge in 3.2.0 [[peephole / fixed]]

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. - The code is in:

Re: [fpc-devel] Moving to gitlab.

On 29/07/2021 22:16, Luca Olivetti via fpc-devel wrote: El 29/7/21 a les 17:52, Michael Van Canneyt via fpc-devel ha escrit: For clarity: the lazarus issues have already been transferred, the FPC ones not yet; there is an issue with the svn -> git conversion. (we need the git conversion to be

Re: [fpc-devel] [fpc-pascal] Moving to gitlab.

On 22/07/2021 18:31, John Lee via fpc-devel wrote: I use viewvc to look at repository - is there an equivalent when everyting is on gitlaB? tia john https://wiki.lazarus.freepascal.org/FPC_git#Windows_Git_clients TortoiseGit is really good on Windows. And you can see things online

Re: [fpc-devel] Moving to gitlab.

On 22/07/2021 18:20, Martin Frb via fpc-devel wrote: On 22/07/2021 15:55, J. Gareth Moreton via fpc-devel wrote: For those who connect to the SVN repository through a command-line terminal to update the trunk, can we have instructions on how to connect to the new GitHub repository this way

Re: [fpc-devel] Moving to gitlab.

On 22/07/2021 15:55, J. Gareth Moreton via fpc-devel wrote: For those who connect to the SVN repository through a command-line terminal to update the trunk, can we have instructions on how to connect to the new GitHub repository this way?  The ins git (gitlab or github): both pages have

Re: [fpc-devel] Potential whole program optimization

On 19/07/2021 01:24, J. Gareth Moreton via fpc-devel wrote: The final assembly language of each method is identical. (Note that the trunk is not this efficient just yet... it still leaves a "movq %rcx,%rax" instruction prior to "movl $1,%r8d" and then calls "movq (%rax),%rax" instead of

Re: [fpc-devel] Going to properly investigate that 3.0.2 bug

On 10/07/2021 06:40, J. Gareth Moreton via fpc-devel wrote: Hi everyone, So I want to fix that optimisation bug in FPC 3.0.2 and 3.2.0 etc, but I need a little bit of help.  I know that Lazarus doesn't build properly with optimisations, but does anyone know of a smaller project that compiles

Re: [fpc-devel] FPC & Lazarus moving to gitlab

On 23/06/2021 00:09, Ryan Joseph via fpc-devel wrote: On Jun 22, 2021, at 4:02 PM, Sven Barth wrote: The plan has *never* been GitHub. The original plan was self hosted with a *mirror* on GitHub. Now we'll instead use GitLab as main repository with a mirror on GitHub. How does the

Re: [fpc-devel] FPC & Lazarus moving to gitlab

On 22/06/2021 23:40, Ryan Joseph via fpc-devel wrote: On Jun 22, 2021, at 10:05 AM, Michael Van Canneyt via fpc-devel wrote: The date for the final conversion has been established as the weekend of 17/18 july. People that wish to report bugs after that will have to create a gitlab account

Re: [fpc-devel] Anyone an idea were/how to look for the missing merge in 3.0.2

On 09/06/2021 09:29, Pierre Muller via fpc-devel wrote:   Martin, could you check if this relates to bug #38973? https://bugs.freepascal.org/view.php?id=38973  This bug also does not show in current trunk.  If you get the same pattern of failures, it is most probably related to this wrong

Re: [fpc-devel] Anyone an idea were/how to look for the missing merge in 3.0.2

On 09/06/2021 09:47, Martin Frb via fpc-devel wrote: On 09/06/2021 09:29, Pierre Muller via fpc-devel wrote: could you check if this relates to bug #38973? https://bugs.freepascal.org/view.php?id=38973  This bug also does not show in current trunk.  If you get the same pattern of failures

Re: [fpc-devel] Anyone an idea were/how to look for the missing merge in 3.0.2

On 09/06/2021 09:29, Pierre Muller via fpc-devel wrote: could you check if this relates to bug #38973? https://bugs.freepascal.org/view.php?id=38973  This bug also does not show in current trunk.  If you get the same pattern of failures, it is most probably related to this wrong

[fpc-devel] Anyone an idea were/how to look for the missing merge in 3.0.2

I have the following issue. A testcase (LazDebuggerFp/test) works fine. Except for 3.2.0 and 3.2.2 (win 64) with -O3 or -O2 In detail: - It works in 32 bit   3.2.2 --  O3 - It works in 64 bit  3.0.4 / 3.3.1  -- O1 O2 and O3   (My 3.3.1 is 2 weeks old.) - It works in 64 bit  LINUX  3.2.2 

Re: [fpc-devel] Crash in TWriter with read only class property = nil

On 21/05/2021 21:42, Michael Van Canneyt via fpc-devel wrote: Definitely a bug. It should not crash. Please file a bugreport... Done https://bugs.freepascal.org/view.php?id=38920 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

[fpc-devel] Crash in TWriter with read only class property = nil

If you have a readonly property such as (tested with 3.2.2 rc)   TMyComponent = class(TComponent)   private     FFoo: TComponent;   published     property ReadOnly: TComponent read FFoo;   end; and FFoo is nil, then TWriter will crash. Is the above scenario forbidden to be implemented (and

Re: [fpc-devel] TypeInfo GetSetProp and GetEnumName

On 20/05/2021 19:00, Martin Frb via fpc-devel wrote: I would therefore expect (target depended) that "u8inttype" may be aligned? Sorry, forget that part of my previous post. I somehow got to u8 => 8byte => qword, instead

[fpc-devel] TypeInfo GetSetProp and GetEnumName

Looking through some code in unit TypInfo in relation to https://bugs.freepascal.org/view.php?id=38915 RTTI for a set, only specifies the size in bytes. (TTypeDate.SetSize) GetSetProp / SetToString iterate over all bits on the given byte size. Since in many cases this is more than the actual

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

On 19/05/2021 22:10, Sven Barth wrote: Am 18.05.2021 um 15:24 schrieb Martin Frb via fpc-devel: I was looking at TypeInfo (based on 3.2.2rc) . fpc_3.2.2\source\tests\webtbs\tw12038.pp    line 194    procedure DisplayDetails(Informations : TPropInfo; const expectedresult: ansistring

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

On 18/05/2021 15:50, Martin Frb via fpc-devel wrote: On 18/05/2021 15:24, Martin Frb via fpc-devel wrote: line 632  unit TypInfo     tkMethod:   followed by   ResultType : ShortString // for mkFunction, mkClassFunction only

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

On 18/05/2021 15:24, Martin Frb via fpc-devel wrote: I was looking at TypeInfo (based on 3.2.2rc) line 632  unit TypInfo     tkMethod:   followed by   ResultType : ShortString // for mkFunction, mkClassFunction only   ResultTypeRef

[fpc-devel] TypeInfo RTTI / possible inconsistency

I was looking at TypeInfo (based on 3.2.2rc) line 632  unit TypInfo     tkMethod:   (MethodKind : TMethodKind;    ParamCount : Byte;    ParamList : array[0..1023] of Char {in reality ParamList is a array[1..ParamCount] of:

[fpc-devel] (ref types / circles) Re: Defer keyword

On 07/05/2021 01:36, Nikolai Zhubr via fpc-devel wrote: Indeed. However, unfortunately classes are substantially different in that they can cause reference circles, You can already cause ref circles, no classes needed. type   TR = record     a: array of TR;   end; var   x: TR; begin  

[fpc-devel] Quick question on VMT / writeable or protected memory

Opening a can of worms here. But leaving all pitfalls aside. If one wanted to write to the VMT of a class, would that be possible? Would the VMT be stored in write-able memory, once the exe is loaded? Thanks ___ fpc-devel maillist -

[fpc-devel] String constant truncation - Bug in 3.2.2rc

Just for info: https://forum.lazarus.freepascal.org/index.php?topic=54050.new ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] function GetCurrentThreadId vs variable ThreadID

I looked at the doc https://www.freepascal.org/docs-html/rtl/system/getcurrentthreadid.html https://www.freepascal.org/docs-html/rtl/system/threadid.html But the entry for ThreadId only says "Current Thread ID." Which is not distinguishing it from GetCurrentThreadId. So what is the difference?

Re: [fpc-devel] Fpc on Windows, how to specify foreign chars in -oExeName commandline

On 27/03/2021 19:14, Marco van de Voort via fpc-devel wrote: Op 2021-03-27 om 19:11 schreef Martin Frb via fpc-devel: On 27/03/2021 18:55, Marco van de Voort via fpc-devel wrote: Op 2021-03-27 om 18:38 schreef Martin via fpc-devel: On Linux I can do fpc -oTestäあProg  MyProg.pas On Windows

Re: [fpc-devel] Fpc on Windows, how to specify foreign chars in -oExeName commandline

On 27/03/2021 18:55, Marco van de Voort via fpc-devel wrote: Op 2021-03-27 om 18:38 schreef Martin via fpc-devel: On Linux I can do fpc -oTestäあProg  MyProg.pas On Windows the Japanese char does not seem to be possible? Did you select a 1-byte Japanese encoding on Windows? Probably not. I

[fpc-devel] Fpc on Windows, how to specify foreign chars in -oExeName commandline

On Linux I can do fpc -oTestäあProg  MyProg.pas On Windows the Japanese char does not seem to be possible? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC 3.2.2-RC1 released!

On 24/03/2021 12:10, Marco van de Voort via fpc-devel wrote: Hello, We have placed the first release candidate of the Free Pascal Compiler version 3.2.2 on our ftp servers. Just run the testsuite. I got a few errors. Though I did build fpc from svn myself, therefore it might be a problem in

[fpc-devel] fpc trunk / dwarf 4 / lineinfo

Has anything changed with lineinfo for dwarf 4?  (Actually I am not sure if it worked before, but I am unaware of problems before) I updated to latest svn yesterday. So more or less up to date. fpc.exe -B -MObjFPC   -gw4  -O-  -WG   ArgVPrg.pas the "objdump" from

Re: [fpc-devel] FPC 3.2.2-RC1 released!

On 24/03/2021 12:10, Marco van de Voort via fpc-devel wrote: Hello, We have placed the first release candidate of the Free Pascal Compiler version 3.2.2 on our ftp servers. Just run the testsuite. I got a few errors. Though I did build fpc from svn myself, therefore it might be a problem in

Re: [fpc-devel] FPC 3.2.2-RC1 released!

On 24/03/2021 12:10, Marco van de Voort via fpc-devel wrote: Hello, We have placed the first release candidate of the Free Pascal Compiler version 3.2.2 on our ftp servers. There is still an open 3.0.4 regression issue https://bugs.freepascal.org/view.php?id=38442 Afaik it is based on the

Re: [fpc-devel] double free of internal temp string with fpc 3.2.0

On 08/01/2021 17:11, Martin Frb via fpc-devel wrote: I only tested with 3.2.0 so far. Maybe someone recalls if this is fixed or not. Also because it seems to happen only in very rare conditions, it may be that trunk does not cause it in this place even if the bug is not yet fixed. (as other

[fpc-devel] double free of internal temp string with fpc 3.2.0

I only tested with 3.2.0 so far. Maybe someone recalls if this is fixed or not. Also because it seems to happen only in very rare conditions, it may be that trunk does not cause it in this place even if the bug is not yet fixed. (as other code changes could simply change the context enough to

[fpc-devel] TRegExpr serious regression in 3.2.0

In 3.0.4 the below gives true for all 4 lines In 3.2.0 the last 2 matches give false. 0*  does not match 00 when it appears in the middle of an expression program Project1; {$mode objfpc}{$H+} uses   RegExpr; var   FRegX: TRegExpr; begin   FRegX := TRegExpr.Create;   FRegX.ModifierI := True;  

Re: [fpc-devel] 32 bit on linux -- /usr/bin/ld: cannot find -lpthread

On 31/12/2020 17:32, Jonas Maebe via fpc-devel wrote: You also have to install the i386 version of the -dev(el) package. Ah thanks. Now it works. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

[fpc-devel] 32 bit on linux -- /usr/bin/ld: cannot find -lpthread

- I have a 64bit linux. (Fedora 33) - I have a 32 bit ppc to start building => So the 32 bit ppc is not called as cross compiler. It does the compiler cycle (there is a32bit ppc1 ... ppc3 file rel_3.2.0/source/compiler/ppc1 rel_3.2.0/source/compiler/ppc1: ELF 32-bit LSB executable, Intel

[fpc-devel] declaration of GetCharacterPlacementW(

function GetCharacterPlacementW(DC: HDC; p2: LPWSTR; p3, p4: BOOL; var p5: TGCPResults; p6: DWORD): DWORD; external 'gdi32' name 'GetCharacterPlacementW'; Why are p3 and p4 Bool? They should be both int?

Re: [fpc-devel] Proposal/discussion: Simple nested functions and 'outlining'

On 01/10/2020 23:22, J. Gareth Moreton via fpc-devel wrote: In a way, yes, but not quite the same, since multiple calls to the nested function would still redirect to the same block of code rather than being inlined at each call.  I suppose more similar to the old GOSUB; RETURN combination in

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

On 27/09/2020 09:34, Sven Barth via fpc-devel wrote: Ben Grasset via fpc-devel > schrieb am So., 27. Sep. 2020, 07:50: That last quote is absolute BS, to be very frank. There is no reason whatsoever not to use a natively-64-bit copy of FPC if

Re: [fpc-devel] TThread.RemoveQueuedEvents

On 26/09/2020 14:13, Pascal Riekenberg via fpc-devel wrote: Yes, you get no "In Foo"! Thanks... Added documentation request https://bugs.freepascal.org/view.php?id=37819 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] TThread.RemoveQueuedEvents

On 26/09/2020 13:58, Pascal Riekenberg wrote: Hi Martin, there is a free Community Edition. Ok, but maybe someone who already has it installed, can copy and paste the test that I posted? (should barely take half a minute or less) ___ fpc-devel

Re: [fpc-devel] TThread.RemoveQueuedEvents

On 26/09/2020 13:35, Martin Frb via fpc-devel wrote: Unfortunately I do not have Delphi. Can anyone test this? I made a test program If it does not print any "in foo" then it ignores the instance. Otherwise it should print one "in foo". Besides of "what Delphi does&q

<    1   2   3   4   5   6   7   8   9   10   >