Re: [fpc-devel] Dwarf Standard - support for properties

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

[fpc-devel] class property - should this work - static field in nested field

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

[fpc-devel] Dwarf Standard - implementing...

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 mak

Re: [fpc-devel] Dwarf Standard - implementing...

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.

[fpc-devel] Potentially wrong line info with dwarf 4

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,

Re: [fpc-devel] Potentially wrong line info with dwarf 4

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

[fpc-devel] Peephole issue in 3.2.3

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 -

Re: [fpc-devel] Peephole issue in 3.2.3

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

[fpc-devel] DWARF-4 / line info / Re: Freeze of fixes for 3.2.4 by 9th June

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? https://lists.freepasc

Re: [fpc-devel] DWARF-4 / line info / Re: Freeze of fixes for 3.2.4 by 9th June

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

[fpc-devel] DWARF proposal - review (for properties) - question on attributes (stored/default)

https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-May/002424.html While reviewing https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-June/002451.html https://lists.dwarfstd.org/pipermail/dwarf-discuss/2024-June/002462.html I got thinking, are the "stored" and "default" (default for st

Re: [fpc-devel] Unnoticed bug report

On 28/06/2024 09:44, Werner Pamler via fpc-devel wrote: I having the same experience as Laz-dev: I see a report which looks interesting, but cannot address it at the moment. Not sure whether I really can fix the issue I do not assign it to myself at this moment. And later, when I could have a c

[fpc-devel] soft-fpu

Any hints on using unit SoftFpu? (or any alternative) I have an 80 bit float (from an external source) that needs to be converted to double. But if I do   uses softfpu, ufloatx80 then I get   Error: Multiple defined symbol "INT32_TO_FLOAT64" and many more...

Re: [fpc-devel] soft-fpu

On 10/07/2024 23:55, Sven Barth via fpc-devel wrote: The SoftFpu unit is only intended for use by the compiler. If you want to use 80-bit floating point yourself you need to use ufloat80 and sfpux80 (the later wraps the same include files as SoftFpu, but for use by the user). Thanks. Now

[fpc-devel] Maybe missing assigned check? TBasicActionLink.Update

Other functions of  TBasicActionLink have checks like    if FAction <> nil then But "Update" does not. Is that intended? Or shall I bug report it? function TBasicActionLink.Update: Boolean; begin   Result := FAction.Update; end; ___ fpc-devel maillist

[fpc-devel] fpc 3.2.3 freezing entire OS / Linux

Ok, right now, not sure where to start. I have a modified Lazarus source, that I am trying to build. Only, when FPC tries to compile it, it never returns. And freezes my Fedora (in a Virtualbox). It will eventually (after an hour or longer) be killed by the OS. Which at least at one time repor

Re: [fpc-devel] fpc 3.2.3 freezing entire OS / Linux

On 17/08/2024 17:25, Martin Frb via fpc-devel wrote: Ok, right now, not sure where to start. I have a modified Lazarus source, that I am trying to build. I tried with -va it stopped a lot faster 90.461] (1) Unitsearch: /home/m/laz/lazgit/components/datetimectrls/design/lib/x86_64-linux

[fpc-devel] RETRACTED Re: fpc 3.2.3 freezing entire OS / Linux

Sorry, seems the VM itself went bonkers. All fine after a reboot of the guest system. On 17/08/2024 18:27, Martin Frb via fpc-devel wrote: On 17/08/2024 17:25, Martin Frb via fpc-devel wrote: Ok, right now, not sure where to start. I have a modified Lazarus source, that I am trying to build

[fpc-devel] Unfortunately still an issue .... [[Re: fpc trunk / parentfp for debugger / missing]]

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. There are still cases where it goes wrong. (tested on

Re: [fpc-devel] Unfortunately still an issue (Solved) .... [[Re: fpc trunk / parentfp for debugger / missing]]

On 20/08/2020 19:00, Yuriy Sydorov via fpc-devel wrote: Fixed in r46514. Thanks, looks ok now. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Exact details for RTLeventWaitFor and related ?

On 22/08/2020 03:50, Kirinn via fpc-devel wrote: When I researched synchronisation behavior and wrote the wiki page "Threads", I found that RTL events behave like this: - When the event is set, a single waiting thread is released (in FIFO order), and the event is automatically immediately rese

Re: [fpc-devel] Dwarf and "Result"

On 22/08/2020 13:54, Jonas Maebe via fpc-devel wrote: Lowercase variables cannot be accessed directly by Pascal code, and only by the compiler itself (or through absolute aliases). Gdb shows all 3 values in the locals -stack-list-locals So the double "result"/"RESULT" is irritating. Anyway it

Re: [fpc-devel] TThread.Terminate;

Is there some really good article (better than the wikipedia https://en.wikipedia.org/wiki/Memory_barrier) on - memory barrier vs - cache coherency vs interlocked ? On 22/08/2020 16:57, Jonas Maebe via fpc-devel wrote: Very important: InterlockedExchange is not a memory barrier, except on x8

Re: [fpc-devel] TThread.Terminate;

On 22/08/2020 17:39, Martin Frb via fpc-devel wrote: Is there some really good article (better than the wikipedia https://en.wikipedia.org/wiki/Memory_barrier) on - memory barrier vs - cache coherency vs interlocked ? From what I found: https://stackoverflow.com/questions/30958375/memory

Re: [fpc-devel] WriteBarrier

On 24/08/2020 19:22, Jonas Maebe via fpc-devel wrote: On 24/08/2020 19:20, Jonas Maebe via fpc-devel wrote: It's not paranoid, it is the only correct way to write the code. * if you don't want to use regular synchronisation primitives, like mutexes/signals/events/... I have events in some ca

Re: [fpc-devel] TThread.RemoveQueuedEvents

On 25/09/2020 13:03, Ondrej Pokorny via fpc-devel wrote: On 25.09.2020 03:30, Martin via fpc-devel wrote: Does the "given method" mean: 1) "aMethod" as passed in as parameter, consisting of proc and instance 2) "method of the class" extracted from "aMethod" It's a Delphi-compatibility method:

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

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 mailli

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 https://lists.freepas

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 r

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 o

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 https://lists.freepascal.org/cgi-bin/mailman/

[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;  

[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

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

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 u

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

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

[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] 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@lists.f

[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   SetLen

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

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

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

[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 amou

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] 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 ther

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 https://lists.

[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] 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 optimizati

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

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 in

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 mirrori

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] 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 "movq

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 fu

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] [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 https://

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] 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: components\lazutils\lazcollections.p

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 in

[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 thei

[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' B:/FPC/SVN/fpc_build//install

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

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

[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* / |TObject

[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 in

[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 "Boole

[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 thi

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

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 compile

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; pr

[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:    Length

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

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] 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 demonstrat

[fpc-devel] fpc bug with M1

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 generator for M1 var pn8: pint8; // pointer signed byte In the below expression ...(not pn8^)... "pn8^" is loaded to w0 and sign extended. From this point onwards ope

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.

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 "c

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

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 https://forum.lazarus.freepascal.org/index.php/topic,44985.msg317072.h

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 exi

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

Hi Gareth, not sure if this is of interest to you, but I see you do a lot on the optimizer While testing the attached, I found that one of the functions was notable slower when compiled with 3.3.1 (compared to 3.2.3). So maybe something you are interested in looking at? The Code in "Utf

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 UTF8LengthF

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 makes

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 r

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 possible

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. (If the

[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 15

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

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 again

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 (su

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

[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 3

[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] 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 d

  1   2   3   >