Re: [fpc-devel] @J. Gareth / Kit: Idea for peephole

C++ allows this kind of optimization - see https://godbolt.org/z/YTf3dKGrd For suppressing this and other possible optimizations, there is the volatile keyword. From what I have seen in Delphi so far, it always considers all memory access to be volatile. If that is just a matter of missing opti

Re: [fpc-devel] ASM One register allocated twice at once ? 3.3.1 peephole / # Register r10, r15, r15 allocated

I've assigned it to myself and will take a look over the next few days.  You sometimes do get double allocations in the disassembly - that in itself shouldn't cause problems beyond being a bit redundant, Kit On 30/09/2025 13:54, Martin Frb via fpc-devel wrote: Confirmed wrong/bad asm code gen

Re: [fpc-devel] ASM One register allocated twice at once ? 3.3.1 peephole / # Register r10, r15, r15 allocated

Confirmed wrong/bad asm code generation after the reported comment https://gitlab.com/freepascal.org/fpc/source/-/issues/41422 On 30/09/2025 10:59, Martin Frb via fpc-devel wrote: 3.3.1 d3ac07ad274b6c6b09ff9b08a9d7007aaf780aa6 I am currently tracking an issue (either my code, or the peephole

Re: [fpc-devel] Do type-helpers block "regvar" opt?

Martin Frb via fpc-devel schrieb am Mo., 29. Sep. 2025, 14:58: > On 29/09/2025 14:17, Sven Barth via fpc-devel wrote: > > Martin Frb via fpc-devel schrieb am Mo., > 29. Sep. 2025, 12:30: > >> Tested with 3.3.1 d3ac07ad27 >> -O4 >> Win 64 bit >> >> In the code below, compiled with -alr >> .s

Re: [fpc-devel] if-then-else expression

Benito van der Zander via fpc-devel schrieb am Mo., 8. Sep. 2025, 00:40: > Hi, > > Implicit function specialization would change that, however that would > mean the generation of a specialized definition each time it is used in a > different unit and for every type. > > > This calls for a space o

Re: [fpc-devel] if-then-else expression

Hi, Implicit function specialization would change that, however that would mean the generation of a specialized definition each time it is used in a different unit and for every type. This calls for a space optimizer that removes unnecessary specializations 3 optimizations could one have:

Re: [fpc-devel] if-then-else expression

Michael Van Canneyt via fpc-devel schrieb am Sa., 6. Sep. 2025, 20:53: > > > On Sat, 6 Sep 2025, Sven Barth via fpc-devel wrote: > > > michael via fpc-devel schrieb am Do., > 4. > > Sep. 2025, 09:29: > > > >> On 2025-09-04 08:55, Hairy Pixels via fpc-devel wrote: > >>> On Sep 4, 2025 at 1:43:23 

Re: [fpc-devel] if-then-else expression

On Sat, 6 Sep 2025, Sven Barth via fpc-devel wrote: michael via fpc-devel schrieb am Do., 4. Sep. 2025, 09:29: On 2025-09-04 08:55, Hairy Pixels via fpc-devel wrote: On Sep 4, 2025 at 1:43:23 PM, michael via fpc-devel wrote: Personally, I think we already have too much intrinsics to beg

Re: [fpc-devel] if-then-else expression

michael via fpc-devel schrieb am Do., 4. Sep. 2025, 09:29: > On 2025-09-04 08:55, Hairy Pixels via fpc-devel wrote: > > On Sep 4, 2025 at 1:43:23 PM, michael via fpc-devel > > wrote: > > > >> Personally, I think we already have too much intrinsics to begin > >> with; > >> no matter their behavio

Re: [fpc-devel] if-then-else expression

On 2025-09-04 08:55, Hairy Pixels via fpc-devel wrote: On Sep 4, 2025 at 1:43:23 PM, michael via fpc-devel wrote: Personally, I think we already have too much intrinsics to begin with; no matter their behaviour. But that is another discussion entirely... How so? The reason intrinsics are us

Re: [fpc-devel] if-then-else expression

On Sep 4, 2025 at 1:43:23 PM, michael via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Personally, I think we already have too much intrinsics to begin with; > no matter their behaviour. But that is another discussion entirely... > How so? The reason intrinsics are used is because they c

Re: [fpc-devel] if-then-else expression

On 2025-09-04 08:05, Sven Barth via fpc-devel wrote: Michael Van Canneyt via fpc-devel schrieb am Di., 2. Sep. 2025, 14:28: On Tue, 2 Sep 2025, Sven Barth via fpc-devel wrote: Hairy Pixels via fpc-devel schrieb am Di., 2. Sep. 2025, 09:50: On Sep 1, 2025 at 3:44:17 PM, Nikolay Nikolov v

Re: [fpc-devel] if-then-else expression

Michael Van Canneyt via fpc-devel schrieb am Di., 2. Sep. 2025, 14:28: > > > On Tue, 2 Sep 2025, Sven Barth via fpc-devel wrote: > > > Hairy Pixels via fpc-devel schrieb am > Di., > > 2. Sep. 2025, 09:50: > > > >> On Sep 1, 2025 at 3:44:17 PM, Nikolay Nikolov via fpc-devel < > >> fpc-devel@lists

Re: [fpc-devel] if-then-else expression

On Tue, 2 Sep 2025, Sven Barth via fpc-devel wrote: Hairy Pixels via fpc-devel schrieb am Di., 2. Sep. 2025, 09:50: On Sep 1, 2025 at 3:44:17 PM, Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: You're more likely to see things like: a := if x > 10 then 1 else -1;

Re: [fpc-devel] if-then-else expression

Hairy Pixels via fpc-devel schrieb am Di., 2. Sep. 2025, 09:50: > On Sep 1, 2025 at 3:44:17 PM, Nikolay Nikolov via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> You're more likely to see things like: >> >> a := if x > 10 then 1 else -1; >> >> instead of >> >> if x > 10 then >> a :=

Re: [fpc-devel] if-then-else expression

On Sep 1, 2025 at 3:44:17 PM, Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > You're more likely to see things like: > > a := if x > 10 then 1 else -1; > > instead of > > if x > 10 then > a := 1 > else > > a := -1; > > Yes I agree but in C-like languages I do use it i

Re: [fpc-devel] if-then-else expression

On 8/29/25 5:30 PM, Hairy Pixels via fpc-devel wrote: On Aug 28, 2025 at 5:10:56 AM, Sven Barth via fpc-devel wrote: Also there *will* be the if-then-expression, the question is only when the merge request is finalized enough (I currently can't check, so I can't comment on any progress there)

Re: [fpc-devel] if-then-else expression

Op 29-8-2025 om 16:30 schreef Hairy Pixels via fpc-devel: On Aug 28, 2025 at 5:10:56 AM, Sven Barth via fpc-devel wrote: Also there *will* be the if-then-expression, the question is only when the merge request is finalized enough (I currently can't check, so I can't comment on any progress th

Re: [fpc-devel] if-then-else expression

On Aug 28, 2025 at 5:10:56 AM, Sven Barth via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > Also there *will* be the if-then-expression, the question is only when the > merge request is finalized enough (I currently can't check, so I can't > comment on any progress there). > I didn’t rea

Re: [fpc-devel] Broken cookies?

Wonderful. Many thanks. On Sat 30 Aug 2025, 10:57 Michael Van Canneyt via fpc-devel, < fpc-devel@lists.freepascal.org> wrote: > > > Fixed in trunk, and I fixed some other issues as well while testing. > > Michael. > > On Sat, 30 Aug 2025, Michael Van Canneyt via fpc-devel wrote: > > > > > > > On

Re: [fpc-devel] Broken cookies?

Fixed in trunk, and I fixed some other issues as well while testing. Michael. On Sat, 30 Aug 2025, Michael Van Canneyt via fpc-devel wrote: On Fri, 29 Aug 2025, David Connolly via fpc-devel wrote: Hi all, I have a small test program simple.pas (included) When I compile and run it I ge

Re: [fpc-devel] Broken cookies?

On Fri, 29 Aug 2025, David Connolly via fpc-devel wrote: Hi all, I have a small test program simple.pas (included) When I compile and run it I get an exception. I've traced the problem to some cookie changes made to *fphttpclient.pp*. Bypassing that, there's another problem handling the for

Re: [fpc-devel] if-then-else expression

Parameter evaluation order is ub so you cannot rely on that, regardless of inlining. And even though the intrinsic could behave differently it still looks like a regular function call and also might clash with existing similarly named existing function. > On 27/08/2025 16:40 CEST Hairy Pixels v

Re: [fpc-devel] if-then-else expression

Hairy Pixels via fpc-devel schrieb am Do., 28. Aug. 2025, 09:55: > On Aug 26, 2025 at 3:49:43 AM, Nikolay Nikolov via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> But they're not 100% compatible, are they? IfThen evaluates both the true >> and the false parameter, while the 'if' stat

Re: [fpc-devel] if-then-else expression

Hairy Pixels via fpc-devel schrieb am Di., 26. Aug. 2025, 09:53: > On Aug 24, 2025 at 3:28:45 PM, Karoly Balogh via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> The new syntax has strong Python vibes to me. This is where I saw/used >> this the most. Which is not necessarily a bad thi

Re: [fpc-devel] if-then-else expression

On 8/27/25 16:40, Hairy Pixels via fpc-devel wrote: On Aug 26, 2025 at 3:49:43 AM, Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: [] I think if the call was inlined it wouldn’t but otherwise it would. Inlining must not change the behavior. Nikolay is right, that

Re: [fpc-devel] if-then-else expression

On Aug 26, 2025 at 3:49:43 AM, Nikolay Nikolov via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > But they're not 100% compatible, are they? IfThen evaluates both the true > and the false parameter, while the 'if' statement doesn't. For example: > > s := IfThen(b <> 0, a div b, 999) > > Wil

Re: [fpc-devel] if-then-else expression

On 8/25/25 5:27 PM, Hairy Pixels via fpc-devel wrote: On Aug 24, 2025 at 3:28:45 PM, Karoly Balogh via fpc-devel wrote: The new syntax has strong Python vibes to me. This is where I saw/used this the most. Which is not necessarily a bad thing. My code is usually very oldschool and I tend to av

Re: [fpc-devel] if-then-else expression

On Aug 24, 2025 at 3:28:45 PM, Karoly Balogh via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > The new syntax has strong Python vibes to me. This is where I saw/used > this the most. Which is not necessarily a bad thing. My code is usually > very oldschool and I tend to avoid most of the "

Re: [fpc-devel] if-then-else expression

Hi, On Sat, 23 Aug 2025, Sven Barth via fpc-devel wrote: >> You were almost 10 years ahead :) >> >> https://blogs.embarcadero.com/coming-in-rad-studio-13-a-conditional-ternary-operator-for-the-delphi-language/ > > Oxygene already had it for longer which is where I had the idea from 😅 The new syn

Re: [fpc-devel] if-then-else expression

Ondrej Pokorny via fpc-devel schrieb am Do., 21. Aug. 2025, 23:49: > On 01.02.2016 21:14, Sven Barth wrote: > > Hello together! > > > > Time for the next flame. I've attached a patch which implements an "if > > Condition then ThenExpr else ElseExpr"-expression for those that want to > > play arou

Re: [fpc-devel] if-then-else expression

On 01.02.2016 21:14, Sven Barth wrote: Hello together! Time for the next flame. I've attached a patch which implements an "if Condition then ThenExpr else ElseExpr"-expression for those that want to play around with it. It follows the same principles as the yet-to-be-renamed IfThen() (namely tha

Re: [fpc-devel] Test

On 8/20/25 10:39 AM, Ondrej Pokorny via fpc-devel wrote: On 20.08.2025 16:15, wkitty42--- via fpc-devel wrote: On 8/20/25 9:20 AM, Werner Pamler via fpc-devel wrote: Sending this "test" message because I received the last message from this mailing three weeks ago. same here... it seems to be

Re: [fpc-devel] Test

On 20.08.2025 16:15, wkitty42--- via fpc-devel wrote: On 8/20/25 9:20 AM, Werner Pamler via fpc-devel wrote: Sending this "test" message because I received the last message from this mailing three weeks ago. same here... it seems to be working, tho... I sent an email earlier today to this li

Re: [fpc-devel] Test

On 8/20/25 9:20 AM, Werner Pamler via fpc-devel wrote: Sending this "test" message because I received the last message from this mailing three weeks ago. same here... it seems to be working, tho... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing l

Re: [fpc-devel] generic forward declaration?

On 7/30/25 13:01, Martin Frb via fpc-devel wrote: On 30/07/2025 12:23, Mattias Gaertner via fpc-devel wrote: [...] pas2js compiles it. OTOH pas2js currently creates 3 internal specializations for each TFoo and TBar. There should only be TFoo TFoo Yes. Well, actually, in your example you

Re: [fpc-devel] generic forward declaration?

On 30/07/2025 12:23, Mattias Gaertner via fpc-devel wrote: On 7/30/25 11:44, Martin Frb via fpc-devel wrote: On 29/07/2025 23:39, Sven Barth via fpc-devel wrote: Please report a bug. Though this might end up not compiling nevertheless due to the specialization chain going ad infinitum...

Re: [fpc-devel] generic forward declaration?

On 7/30/25 11:44, Martin Frb via fpc-devel wrote: On 29/07/2025 23:39, Sven Barth via fpc-devel wrote: Please report a bug. Though this might end up not compiling nevertheless due to the specialization chain going ad infinitum... https://gitlab.com/freepascal.org/fpc/source/-/issues/4134

Re: [fpc-devel] generic forward declaration?

On 29/07/2025 23:39, Sven Barth via fpc-devel wrote: Please report a bug. Though this might end up not compiling nevertheless due to the specialization chain going ad infinitum... https://gitlab.com/freepascal.org/fpc/source/-/issues/41349 It does not need to go ad infinitum. In the interf

Re: [fpc-devel] generic forward declaration?

Martin Frb via fpc-devel schrieb am Di., 29. Juli 2025, 20:57: > On 29/07/2025 09:36, Michael Van Canneyt wrote: > > Same here, you're missing a type parameter. TFoo needs 2 type parameters. > > Ups, thanks. > > Any obvious (or non obvious) mistake of mine in the below? > > Because either of the

Re: [fpc-devel] generic forward declaration?

On 29/07/2025 09:36, Michael Van Canneyt wrote: Same here, you're missing a type parameter. TFoo needs 2 type parameters. Ups, thanks. Any obvious  (or non obvious) mistake of mine in the below? Because either of the 2 commented specialize cause errors in the generics... (but only if TFoo.F 

Re: [fpc-devel] generic constraints...

On 29/07/2025 09:53, Mattias Gaertner via fpc-devel wrote: On 7/25/25 16:31, Martin Frb via fpc-devel wrote: But     generic FooChild = class(F) - F is not a variable - TFoo in not a type (for somethnig), TFoo is a constraint The problem is the ambiguity of TFoo, because Delphi (aka modeswi

Re: [fpc-devel] generic constraints...

On Tue, 29 Jul 2025, Mattias Gaertner via fpc-devel wrote: And each list needs to be   TMyFinalItem1 =    specialize TFeatureXForList<    specialize TFeatureYForList<    specialize TFeatureZForList< specialize TFpgList   >   >   >; IMO that does no

Re: [fpc-devel] generic constraints...

On 7/25/25 16:31, Martin Frb via fpc-devel wrote: On 25/07/2025 15:20, Mattias Gaertner via fpc-devel wrote: On 7/25/25 13:44, Martin Frb via fpc-devel wrote: Currently you can't do type    generic TFoo = class   procedure Bar; virtual;    end;    generic FooChild = class(F)   pro

Re: [fpc-devel] generic forward declaration?

On Tue, 29 Jul 2025, Martin Frb via fpc-devel wrote: Are there? Or is there something else? The below compiles. No duplicate TBar. Looks like a forward declaration... program Project1;{$Mode objfpc} type   generic TBar = class; // forward   generic TBar = class     F:A;     X:B;   end; beg

Re: [fpc-devel] generic constraints...

On 25/07/2025 15:20, Mattias Gaertner via fpc-devel wrote: On 7/25/25 13:44, Martin Frb via fpc-devel wrote: Currently you can't do type    generic TFoo = class   procedure Bar; virtual;    end;    generic FooChild = class(F)   procedure Bar; override;    end; Can you use:    gene

Re: [fpc-devel] generic constraints...

On 7/25/25 13:44, Martin Frb via fpc-devel wrote: Currently you can't do type   generic TFoo = class procedure Bar; virtual;   end;   generic FooChild = class(F) procedure Bar; override;   end; Can you use: generic FooChild = class(specialize TFoo) procedure Bar; o

Re: [fpc-devel] "class of TFoo".Create

Going by what Martin just said, should this throw a warning, at least if not in Delphi mode?  Or an error?  This "feature" being used is more likely due to a programming bug and I feel that the developer's attention should be drawn to it so it can be replaced with TFoo.Create if that's what the

Re: [fpc-devel] "class of TFoo".Create

Op 6-7-2025 om 16:31 schreef J. Gareth Moreton via fpc-devel: What I mean is that if you want to instantiate an object of class TFoo, you'd call TFoo.Create, not TFooClass.Create. I also don't see the real value of that "feature", but iirc it was added since Delphi allows it.

Re: [fpc-devel] "class of TFoo".Create

On 06/07/2025 16:17, Zoë Peterson via fpc-devel wrote: I would personally call that unusual at best What do you two expect this construct to do that you think the current behavior is wrong? It’sobviously correct and expected to me as a fundamental part of Object Pascal’s polymorphism. Const

Re: [fpc-devel] "class of TFoo".Create

What I mean is that if you want to instantiate an object of class TFoo, you'd call TFoo.Create, not TFooClass.Create. If you want to take advantage of Object Pascal's unique polymorphism and instantiate a descendant class of TFoo, you'd call MetaClassVariable.Create rather than TFooClass.Creat

Re: [fpc-devel] "class of TFoo".Create

> I would personally call that unusual at best What do you two expect this construct to do that you think the current behavior is wrong? It’sobviously correct and expected to me as a fundamental part of Object Pascal’s polymorphism. Constructing an object from a class reference is the entire

Re: [fpc-devel] "class of TFoo".Create

I would personally call that unusual at best.  Logically I would consider it a type mismatch or a syntax error of some kind, since TFoo is a class and TFooClass is a metaclass.  Also, if I saw such code in a project, I would think someone made a mistake that didn't get caught, since TFoo.Create

Re: [fpc-devel] "class of TFoo".Create

On Sun, Jul 6, 2025 at 1:57 PM Martin Frb via fpc-devel wrote: > program Project1; > {$mode objfpc} > type TFoo = class end; > TFooClass = class of TFoo; > var f: TFoo; > fc: TFooClass; > begin >fc := TFoo; >f := fc.Create; >f := TFooClass.Create; // works > end. Delph

Re: [fpc-devel] fpc_ compilerproc

On Wed, 25 Jun 2025, Mattias Gaertner via fpc-devel wrote: On 6/25/25 08:42, J. Gareth Moreton via fpc-devel wrote: If I'm right in thinking, things like "fpc_abs_real" are fallback functions that have to be overridden by a platform-specific implementation, and return runtime errors if the

Re: [fpc-devel] fpc_ compilerproc

On 6/25/25 08:42, J. Gareth Moreton via fpc-devel wrote: If I'm right in thinking, things like "fpc_abs_real" are fallback functions that have to be overridden by a platform-specific implementation, and return runtime errors if they aren't implemented. In many cases, such internal compiler ro

Re: [fpc-devel] fpc_ compilerproc

If I'm right in thinking, things like "fpc_abs_real" are fallback functions that have to be overridden by a platform-specific implementation, and return runtime errors if they aren't implemented.  In many cases, such internal compiler routines are not called at all because there's a direct inst

Re: [fpc-devel] FPC 3.2.4-rc1 available

> You can help improve the upcoming 3.2.4 release by downloading and > testing this release. I tested the FPC 3.2.4-rc1 on Castle Game Engine, and examples from repos on https://github.com/modern-pascal/ . I found one issue, reported as https://gitlab.com/freepascal.org/fpc/source/-/issues/41300 .

Re: [fpc-devel] FPC 3.2.4-rc1 available

I hope there's time for this.  If this merge request is approved, can it be cherry-picked for 3.2.4 as well? https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/1049 It fixes a bug in the register allocator that I have reason to believe has been around for some time. Kit On 21/06/

Re: [fpc-devel] FPC 3.2.4-rc1 available

Florian Klämpfl via fpc-devel wrote: Hello, As some might have noticed, We have placed the first release candidate of the Free Pascal Compiler version 3.2.4 on our download servers already for some time. Below test program compiles with fpc-3.2.2. but not with fpc-3.2.4 rc1 This is on Mac

Re: [fpc-devel] FPC 3.2.4-rc1 available

Florian Klämpfl via fpc-devel wrote: I tried building the compiler on macOS 14 using fpc.3.2.2 as the bootstrap compiler. This worked. I am a bit surprised however that the built compiler says What sources did you use?

Re: [fpc-devel] FPC 3.2.4-rc1 available

The wiki links are incorrect and lead to non-existent pages. I downloaded the email to my PC to verify where the links point, and they are indeed incorrect: ~~~ You can help improve the upcoming 3.2.4 release by downloading and testing this release. If you want you can report what you have done =

Re: [fpc-devel] FPC 3.2.4-rc1 available

> Am 20.06.2025 um 12:13 schrieb Adriaan van Os via fpc-devel > : > > > > Florian Klämpfl via fpc-devel wrote: >> Hello, >> As some might have noticed, We have placed the first release candidate of >> the Free Pascal Compiler >> version 3.2.4 on our download servers already for some time. >

Re: [fpc-devel] FPC 3.2.4-rc1 available

Florian Klämpfl via fpc-devel wrote: Hello, As some might have noticed, We have placed the first release candidate of the Free Pascal Compiler version 3.2.4 on our download servers already for some time. Thanks ! Great that there is an RC1 for fpc-3.2.4. I tried building the compiler on

Re: [fpc-devel] Speed of TTestCase

On 17/06/2025 20:05, Michael Van Canneyt via fpc-devel wrote: Thanks, merged. Thanks. Off topic, remember we talked about the TDictionary generic? Any comments on https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/988 ___ fpc-devel mai

Re: [fpc-devel] Speed of TTestCase

On Tue, 17 Jun 2025, Martin Frb via fpc-devel wrote: On 14/06/2025 15:44, Michael Van Canneyt via fpc-devel wrote: But then please do it so the comparison is done only once, i.e. something like: if aExpected=aValue then   Inc(AssertCount) else   Fail(ComparisonMsg(aMessage, aExpected,aVal

Re: [fpc-devel] Speed of TTestCase

On 14/06/2025 15:44, Michael Van Canneyt via fpc-devel wrote: But then please do it so the comparison is done only once, i.e. something like: if aExpected=aValue then   Inc(AssertCount) else   Fail(ComparisonMsg(aMessage, aExpected,aValue),CallerAddress); https://gitlab.com/freepascal.org/f

Re: [fpc-devel] Speed of TTestCase

Hairy Pixels via fpc-devel schrieb am Sa., 14. Juni 2025, 18:20: > On Jun 14, 2025 at 10:50:46 PM, Martin Frb via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> I may... Need to find some time. >> >> Also, what do you think about overloading AssertEquals (and the like) >> taking >> Ass

Re: [fpc-devel] Speed of TTestCase

On Sat, 14 Jun 2025, Martin Frb via fpc-devel wrote: On 14/06/2025 15:44, Michael Van Canneyt via fpc-devel wrote: I have heaps and heaps of testcases, but I've never felt the need to investigate the speed of the Assert* calls. I wasn't actually looking at it... I found it by random chan

Re: [fpc-devel] Speed of TTestCase

On Jun 14, 2025 at 10:50:46 PM, Martin Frb via fpc-devel < fpc-devel@lists.freepascal.org> wrote: > I may... Need to find some time. > > Also, what do you think about overloading AssertEquals (and the like) > taking > AssertEqual( > const AnFormatString: string; > const AFormatData: array of

Re: [fpc-devel] Speed of TTestCase

On 14/06/2025 15:44, Michael Van Canneyt via fpc-devel wrote: I have heaps and heaps of testcases, but I've never felt the need to investigate the speed of the Assert* calls. I wasn't actually looking at it... I found it by random chance. I was trying to kcachegrind some of my code, and the

Re: [fpc-devel] Speed of TTestCase

On Sat, 14 Jun 2025, Martin Frb via fpc-devel wrote: I have/had several tests that took very long to run. I have no figured out that between 50% and 80% of the time, went into concatenating/formatting the message for "AssertEqual" (and related). Yes, some of my tests now run in less than 20

Re: [fpc-devel] Can't run i386-linux tests

Good news - fixed it!  After studying the full log more closely, I learnt which configuration file it was reading (~/.fpc.cfg), and found the problem. For some reason, all of the directories listed "-Fuusr//lib..." etc. instead of "-Fu/usr/lib...".  I think I accidentally typed the root direc

Re: [fpc-devel] Can't run i386-linux tests

The reason why you didn't get the ZIP is because I forgot to attach the bloody thing!! Oops.  Here it is. However, if it doesn't attach, in the interin, these are the relevant lines from the log: Searching file redir.pp... found (REDIR)    Adding dependency: REDIR depends on UNIX (REDIR)    L

Re: [fpc-devel] Can't run i386-linux tests

On 2025-06-13 16:04, J. Gareth Moreton via fpc-devel wrote: Hi Gareth, Here's the full log (as a ZIP since the raw text file is over 100kB in size). I did do a search of "process.*" in the "/usr/lib/fpc/3.2.2" directory and only found "process.ppu", "process.o" and "process.rsj" in the "unit

Re: [fpc-devel] Can't run i386-linux tests

Hi Gareth, you will need to send me this zip file directly, the list manager software refused to let it go through. Pierre Le 13/06/2025 à 16:04, J. Gareth Moreton via fpc-devel a écrit : Hi Pierre, Here's the full log (as a ZIP since the raw text file is over 100kB in size). I did do a se

Re: [fpc-devel] Can't run i386-linux tests

Hi Pierre, Here's the full log (as a ZIP since the raw text file is over 100kB in size). I did do a search of "process.*" in the "/usr/lib/fpc/3.2.2" directory and only found "process.ppu", "process.o" and "process.rsj" in the "units/i386-linux/fcl-process" subdirectory - no source file.  Do

Re: [fpc-devel] Can't run i386-linux tests

Could you please add OPT="-vwnihut" to the make call? It probably has a problem with the process unit from release installation... But I would like to confirm that this is indeed the issue. Pierre Le 13/06/2025 à 13:08, J. Gareth Moreton via fpc-devel a écrit : Hi Pierre, Here attached is the

Re: [fpc-devel] Can't run i386-linux tests

Hi Pierre, Here attached is the log of me running 'make' for the test suite.  It doesn't matter how far back I go in the commit history or what compiler options I specify - it falls over at the same point. Gareth aka. Kit On 13/06/2025 07:22, Pierre Muller via fpc-devel wrote: Hi Gareth, y

Re: [fpc-devel] Can't run i386-linux tests

Hi Gareth, your email is not detailed enough so that we can really help you. Using a compiler: TEST_OPT=~/Documents/fpc-opts/compiler/ppc386 as option is certainly not working... But your error is probably due to an installation issue. The dotest program will be compiled using your default Fre

Re: [fpc-devel] cnetdb.pp Compile Error on both trunk and stable (MacOSX aarch64)

On 08/06/2025 12:59, Michael Ring via fpc-devel wrote: When trying to build fpc (with fpcupdeluxe) I get the following error for both Trunk and Stable(!!) version of fpc: Compiling ./fcl-net/src/cnetdb.pp cnetdb.pp(240,2) Error: User defined: fatal 'Please consult the netdb.h file for your sy

Re: [fpc-devel] APX instruction set

ly to message - Subject: Re: [fpc-devel] APX instruction set Date: trešd., 2025. g. 21. maijs 21:37 From: J. Gareth Moreton via fpc-devel < fpc-devel@lists.freepascal.org> To: < fpc-devel@lists.freepascal.org>   FPC is always going to be a bit behind the curve because gcc,

Re: [fpc-devel] APX instruction set

FPC is always going to be a bit behind the curve because gcc, for example, has corporate sponsors.  Heck, when I interviewed for a role at ARM (which I didn't get), they made clear that they help develop GCC and LLVM directly.  Can't easily compete with the actual CPU manufacturers contributing

Re: [fpc-devel] What status of the next FPC release?

On Tue, 20 May 2025, Bishop via fpc-devel wrote: Hi guys. There is long time pass since i seen last information about FPC development progress and it next release. The FPC website in no update too. So i want ask: 1) What is next version of FPC planned to release? Is it 3.2.4? Yes. 2) Whe

Re: [fpc-devel] Test fix

That sounds like a good idea.  Let me see what I can do. Kit On 26/04/2025 23:19, Pierre Muller via fpc-devel wrote: You can do that if you want, maybe it would also be better to avoid all benchmark results writing in this conformance configuration as there is not enough averaging, and because

Re: [fpc-devel] Test fix

You can do that if you want, maybe it would also be better to avoid all benchmark results writing in this conformance configuration as there is not enough averaging, and because in many cases the time interval is too short to get any value. Pierre Le 26/04/2025 à 23:50, J. Gareth Moreton via f

Re: [fpc-devel] Test fix

If it's okay, can I rename the define from "IN_TESTS" to "CONFORMANCE" or similar?  Technically, the code in "bcase" and "bfloatfunc" are still tests, but by default are benchmarking tests evaluating performace rather than conformance tests verifying that the compiler has produced correct code.

Re: [fpc-devel] tests/test/tset6.pp failure

Le 26/04/2025 à 01:07, J. Gareth Moreton via fpc-devel a écrit : Hi everyone, I'm curious behind the continuous failure of tests/test/tset6.pp - is it a feature that hasn't been implemented yet or a parser problem? Sets with more than 256 elements has never been implemented into the compi

Re: [fpc-devel] Test fix

"Just one small remark: why do you use '$8' instead of simply '8'?" Mostly habit because the tests use "Iteration and 7" to select the index, so I use $8 for the count to indicate that the bitwise nature of it is important. Kit On 25/04/2025 21:31, Pierre Muller via fpc-devel wrote: Hi,  

Re: [fpc-devel] Test fix

Hi, I add the IN_TESTS conditional code to avoid getting timeout related failures, inside testsuite. I didn't notice that more than one iteration was needed for bfloatfunc.pp, because I tried it with ITERATIONS=1 and it seemed to finish without failure... I have no objection to your patch

Re: [fpc-devel] heap.inc evo when

> Am 18.04.2025 um 15:44 schrieb Michael Van Canneyt via fpc-devel > : > > > > On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: > >> >> >>> Am 18.04.2025 um 15:10 schrieb Michael Van Canneyt via fpc-devel >>> : >>> >>> >>> >>> On Fri, 18 Apr 2025, Michael Van Canneyt via fpc-d

Re: [fpc-devel] heap.inc evo when

18.04.2025 16:53, Florian Klämpfl via fpc-devel пишет: ? Does it work for you? No, I get the same. But I only checked the workings of git log. But now I understand correctly what you meant by "line history" : the "git blame" output. I implicitly assumed you meant 'linear history' :-( Yes

Re: [fpc-devel] heap.inc evo when

On 18/04/2025 15:23, Florian Klämpfl via fpc-devel wrote: I checked, I can do "git log" on both files, and I get the full history (for oldheap.inc you need to add --follow to get it) Is this not what you wanted ? When I do git blame I get: c8bf474d6d0 (Michaël Van Canneyt 2025-04-18 14:4

Re: [fpc-devel] heap.inc evo when

On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: Am 18.04.2025 um 15:10 schrieb Michael Van Canneyt via fpc-devel : On Fri, 18 Apr 2025, Michael Van Canneyt via fpc-devel wrote: On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: Am 18.04.2025 um 14:07 schrieb Micha

Re: [fpc-devel] heap.inc evo when

> Am 18.04.2025 um 15:10 schrieb Michael Van Canneyt via fpc-devel > : > > > > On Fri, 18 Apr 2025, Michael Van Canneyt via fpc-devel wrote: > >> >> >> On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: >> Am 18.04.2025 um 14:07 schrieb Michael Van Canneyt via fpc-devel

Re: [fpc-devel] heap.inc evo when

On Fri, 18 Apr 2025, Michael Van Canneyt via fpc-devel wrote: On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: Am 18.04.2025 um 14:07 schrieb Michael Van Canneyt via fpc-devel : On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: Am 16.04.2025 um 12:00 schrieb Mic

Re: [fpc-devel] heap.inc evo when

On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: Am 18.04.2025 um 14:07 schrieb Michael Van Canneyt via fpc-devel : On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: Am 16.04.2025 um 12:00 schrieb Michael Van Canneyt via fpc-devel : On Wed, 16 Apr 2025, Florian Kl

Re: [fpc-devel] heap.inc evo when

On Fri, 18 Apr 2025, Michael Van Canneyt via fpc-devel wrote: On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: Am 16.04.2025 um 12:00 schrieb Michael Van Canneyt via fpc-devel : On Wed, 16 Apr 2025, Florian Klämpfl via fpc-devel wrote: On 15.04.25 22:52, runewalsh via fpc

Re: [fpc-devel] heap.inc evo when

> Am 18.04.2025 um 14:07 schrieb Michael Van Canneyt via fpc-devel > : > > > > On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: > >> >> >>> Am 16.04.2025 um 12:00 schrieb Michael Van Canneyt via fpc-devel >>> : >>> On Wed, 16 Apr 2025, Florian Klämpfl via fpc-devel wrote: On

Re: [fpc-devel] heap.inc evo when

On Fri, 18 Apr 2025, Florian Klämpfl via fpc-devel wrote: Am 16.04.2025 um 12:00 schrieb Michael Van Canneyt via fpc-devel : On Wed, 16 Apr 2025, Florian Klämpfl via fpc-devel wrote: On 15.04.25 22:52, runewalsh via fpc-devel wrote: What’s the position on MR !694? Person with the yel

  1   2   3   4   5   6   7   8   9   10   >