[fpc-pascal] Regression in 3.2.0 ??
I wondering if there is a regression in 3.2.0. The Lazarus file fpguiwsprivate.pp no longer compiles. It was fine in 3.0.4. The error message "No matching implementation for interface method ... CDecl; found " is strange as the interface and implementation are both clearly defined as stdcall. I can find no reference to CDecl in the release notes, and stdcall only mentioned under Darwin. (I'm using x86_64). function TFPGUIPrivate._AddRef: longint; stdcall; begin Result := -1; end; Has anyone any ideas to fix it? It compiles if I change stdcall to CDecl, but I have no idea if that is a valid fix. (More info; see bug 37566) Regards, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Regression in 3.2.0 ??
Thanks to Sven & Michael for commenting. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Precedence of compiler switches/directives
I'm curious about who wins, if switches/directives are set to different values in different places. They could be set in fpg.cfg Command line or Lazarus lpi Directives in the code. Is there some AND/OR logic, or is it a strict precedence order? Is it the same for all switches? I can see for example that some switches can be turned on but not off at the command line. I gather command line options take precedence over fpc.cfg, but what about directives in the code? If a directive says range checks off, but the command line and/or fpc.cfg says range check on, what happens? I assume that as directives can be set to different values in different parts of the code, that they must have the highest precedence. Is this correct and always the case? Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Why has the tkFloat default value changed?
On 28/02/2021 22:11, Mattias Gaertner via fpc-pascal wrote: Hi, In FPC 3.2.0 the default "Default" value of a single/double property has changed from $8000 (fpc 3.0.4) to 0. This breaks TWriter. The $8000 means the property has no default value. Now FPC 3.2.0 no longer writes a property if the value is 0.0, no matter what the stored function says. For example: property S: Single read FSingle write FSingle stored IsSStored; FPC 3.0.4 TWriter does write S if S=0.0 and IsSStored returns true. FPC 3.2.0 does not. I can't find this change in https://wiki.lazarus.freepascal.org/User_Changes_3.2.0 Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Maybe this is related to bugs 33564 & 31985 ? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Version 3.2.2 changes
Does anyone have a link to useful list of changes or bug fixes for 3.2.2? Both the "New features" & "User Changes" pages are currently rather sparse! https://wiki.freepascal.org/FPC_New_Features_3.2.2 https://wiki.freepascal.org/User_Changes_3.2.2 A release candidate is out, so I assume the contents are pretty much fixed now. Regards, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How does FPC perform in the FASTEST Computer Language Race
On 09/07/2021 23:56, Ryan Joseph via fpc-pascal wrote: On Jul 9, 2021, at 11:40 AM, Wayne Sherman via fpc-pascal wrote: Current standings at the time of this video Iterations per sec: Ada: 67 Pascal: 143 Fastest language: 7301 Slowest language: 1 So Pascal failed pretty bad it looks like. ;) Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Looks like its compiled with no optimisations, |fpc prime ./prime O3 usually makes a big difference. Regards, Peter | ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hello, new Pascal programmer. had a question!
https://castle-engine.io/modern_pascal_introduction.html You can also download it as a single PDF. g. Thanks Dennis. Very useful refresher! Cheers, Pete ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Hello, new Pascal programmer. had a question!
Sorry, my bad. I hadn't got Thunderbird configured right. All mail from this list just showed the list address in the 'From' field. Now fixed it. Edit > Preferences > Advanced > "Show only display name for people in my address book" which was checked. Cheers, Pete ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Broken code with PEEPHOLE & REGVAR
I've been working with a fork of C-evo for a while now. Its been very stable for at least a year. However, recently a game locked up in a (wide) cpu loop. The broken code is in the shared library, built with FPC 3.2.2, its nothing to do with Lazarus, except that Lazarus code calls the library. I compiled a debug version to investigate and the problem went away. It seemed likely that the issue was optimisations, and sure enough, O1 is fine but O2 broken. Trying the optimisations individually I found that PEEPHOLE + REGVAR alone caused the problem. The code actually works fine at O4, providing either PEEPHOLE or REGVAR is disabled. This is with x64 on Debian Linux, but the problem is also on Arch Linux, so nothing specific with the Debian build. Other options like Ct, Ci, Co, CR, Cr make no difference. I tried FPC versions back to 3.0.4, and the issue is still there, so its not a recent regression. Its unlikely that I can reproduce this problem with a small program, but compiling the offending code to assembler, the problem seems rather obvious. Its in a method function, [500] function TBarbarina.DoAttack(uix, AttackLoc: integer): boolean; It seems that parameter AttackLoc is corrupted halfway through the routine, just after being used in an assignment, [587] TestLoc := AttackLoc; If the parameter AttackLoc is used immediately after this statement, for example in a Writeln, its OK. But if not, its corrupted when used later. The problem looks like the register allocator, as at line 587 the assembler comment says that AttackLoc is now in r13d, but r13d has not been initialised. AttackLoc was in 83288(%rsp) up to this point. Here is an extract of the assembler showing statements where AttackLoc is used (to around the point where the problem occurs) . # Var uix located in register eax movl %edx,%eax movq %rax,83288(%rsp) # Var AttackLoc located in register eax # [503] var . # [514] IsBombardment := AttackLoc = maNextCity; movl 83288(%rsp),%eax cmpl $-1,%eax . # [531] if (TestTime >= $800) or (AttackLoc = maNextCity) and (TestTime > $800 - 100) then cmpl $2048,%edx jge .Lj281 movl 83288(%rsp),%eax cmpl $-1,%eax jne .Lj284 cmpl $1948,%edx jg .Lj281 .Lj284: . # [548] AttackLoc := NextLoc; movl %ebx,%eax movq %rax,83288(%rsp) .Lj298: .Lj294: # [550] if (NextLoc = AttackLoc) and ((MyModel[mix].Domain <> dSea) or movl 83288(%rsp),%eax cmpl %ebx,%eax jne .Lj301 movq 83272(%rsp),%rax movq 48(%rax),%rcx movq 83280(%rsp),%rax movzwl 14(%rax),%edx imulq $68,%rdx,%rax cmpb $1,17(%rcx,%rax) jne .Lj302 . # [587] TestLoc := AttackLoc; movl 83288(%rsp),%eax # Var AttackLoc located in register r13d ** movl %eax,24(%rsp) . # [605] until (NextLoc = AttackLoc) or (MoveResult and rExecuted = 0) or cmpl %r12d,%r13d je .Lj332 movl %ebx,%eax andl $1073741824,%eax je .Lj332 . # [607] Result := (NextLoc = AttackLoc) and (MoveResult and rExecuted <> 0); cmpl %r12d,%r13d jne .Lj338 movl %ebx,%eax andl $1073741824,%eax je .Lj338 movb $1,83240(%rsp) jmp .Lj340 .Lj338: movb $0,83240(%rsp) . There are four source files, around 250k, to compile this library. I can supply them if anyone wants to investigate. Is this sufficient for a bug report? Does anyone know of any existing bugs like this? Maybe already fixed? I'll attach the source and assembler for this routine in a follow up mail. Cheers, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR
Attaching source & assembler function TBarbarina.DoAttack(uix, AttackLoc: integer): boolean; // AttackLoc=maNextCity means bombard only var MoveResult, Kind, Temp, MoveStyle, TestLoc, TestTime, NextLoc, NextTime, V8, RecoverTurns, ecix: integer; NextTile: cardinal; AttackPositionReached, IsBombardment: boolean; Adjacent: TVicinity8Loc; PreLoc : tPreLoc; Reached : array[0..lxmax * lymax - 1] of boolean; begin PreLoc := default (tPreLoc); Result := False; IsBombardment := AttackLoc = maNextCity; with MyUnit[uix] do begin if (MyModel[mix].Domain = dGround) and (MyModel[mix].Attack > 0) then if MyModel[mix].Speed >= 250 then Kind := ukFast else Kind := ukSlow else Kind := 0; fillchar(Reached, MapSize, False); AttackPositionReached := False; MoveStyle := GetMyMoveStyle(mix, Health); Pile.Create(MapSize); Pile.Put(Loc, $800 - Movement); while Pile.Get(TestLoc, TestTime) do begin if (TestTime >= $800) or (AttackLoc = maNextCity) and (TestTime > $800 - 100) then break; Reached[TestLoc] := True; V8_to_Loc(TestLoc, Adjacent); for V8 := 0 to 7 do begin NextLoc := Adjacent[V8]; if NextLoc >= 0 then begin if IsBombardment and (Map[NextLoc] and (fCity or fUnit or fOwned or fObserved) = fCity or fObserved) and (RO.Treaty[RO.Territory[NextLoc]] < trPeace) then begin City_FindEnemyCity(NextLoc, ecix); assert(ecix >= 0); with RO.EnemyCity[ecix] do if (Size > 2) and (Flags and ciCoastalFort = 0) then AttackLoc := NextLoc; end; if (NextLoc = AttackLoc) and ((MyModel[mix].Domain <> dSea) or (Map[TestLoc] and fTerrain < fGrass)) then // ships can only attack from water begin AttackPositionReached := True; break; end else if not Reached[NextLoc] then begin NextTile := Map[NextLoc]; if (NextTile and (fUnit or fCity) = 0) or (NextTile and fOwned <> 0) then case CheckStep(MoveStyle, TestTime, V8 and 1, NextTime, RecoverTurns, Map[TestLoc], NextTile, True) of csOk: if Pile.Put(NextLoc, NextTime) then PreLoc[NextLoc] := TestLoc; csForbiddenTile: Reached[NextLoc] := True; // don't check moving there again csCheckTerritory: if RO.Territory[NextLoc] = RO.Territory[TestLoc] then if Pile.Put(NextLoc, NextTime) then PreLoc[NextLoc] := TestLoc; end; end; end; end; if AttackPositionReached then begin PreLoc[NextLoc] := TestLoc; break; end; end; Pile.Free; if not AttackPositionReached then exit; TestLoc := AttackLoc; // if AttackLoc <> TestLoc then // halt; NextLoc := PreLoc[TestLoc]; while TestLoc <> Loc do begin Temp := TestLoc; TestLoc := NextLoc; NextLoc := PreLoc[TestLoc]; PreLoc[TestLoc] := Temp; end; UnitPresence[Loc] := UnitPresence[Loc] and not Kind; // assume unit was only one of kind here repeat NextLoc := PreLoc[Loc]; MoveResult := Unit_Step(uix, NextLoc); until (NextLoc = AttackLoc) or (MoveResult and rExecuted = 0) or (MoveResult and rUnitRemoved <> 0); Result := (NextLoc = AttackLoc) and (MoveResult and rExecuted <> 0); if IsBombardment and Result then begin City_FindEnemyCity(AttackLoc, ecix); assert(ecix >= 0); while (Movement >= 100) and (RO.EnemyCity[ecix].Size > 2) do Unit_Step(uix, AttackLoc); end; if Loc >= 0 then UnitPresence[Loc] := UnitPresence[Loc] or Kind; end; end; .section .text.n_barbarina$_$tbarbarina_$__$$_doattack$longint$longint$$boolean .balign 16,0x90 .globl BARBARINA$_$TBARBARINA_$__$$_DOATTACK$LONGINT$LONGINT$$BOOLEAN .type BARBARINA$_$TBARBARINA_$__$$_DOATTACK$LONGINT$LONGINT$$BOOLEAN,@function BARBARINA$_$TBARBARINA_$__$$_DOATTACK$LONGINT$LONGINT$$BOOLEAN: .Lc25: # Temps allocated between rsp+83236 and rsp+83296 # [511] begin pushq %rbx pushq %r12 pushq %r13 pushq %r14 pushq %r15 leaq-83296(%rsp),%rsp .Lc27: # Var $result located in register al # Var MoveResult located in register ebx # Var Kind located in register eax # Var Temp located in register ecx # Var MoveStyle located in register eax # Var TestLoc located at rsp+24, size=OS_S32 # Var TestTime located at rsp+28, size=OS_S32 # Var NextLoc located in register ebx # Var NextTime located at rsp+32, size=OS_S32 # Var V8 located in register r12d # Var RecoverTurns located at rsp+36, size=OS_S32 # Var ecix located at rsp+40, size=OS_S32 #
Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR
On 10/03/2022 22:46, Sven Barth via fpc-pascal wrote: Peter via fpc-pascal schrieb am Do., 10. März 2022, 23:39: There are four source files, around 250k, to compile this library. I can supply them if anyone wants to investigate. Is this sufficient for a bug report? Does anyone know of any existing bugs like this? Maybe already fixed? Would you please check whether it also occurs with 3.2.3 (which will become the next release soon) or 3.3.1 (the development version)? Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Hi Sven, Pleased to report that with version "Free Pascal Compiler version 3.3.1-10685-gf6ac49a139-unpushed-dirty [2022/03/08] for x86_64" it seems fine. Is there a prebuild Linux binary for 3.2.3/4 anywhere? Cheers, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR
So it seems it was fixed in main at least. Now the interesting question is 3.2.3... Hi Sven, I found a 3.2.3 in ftp://ftp.freepascal.org/pub/fpc/snapshot/v32/x86_64-linux Testing with version Free Pascal Compiler version 3.2.3 [2022/03/05] for x86_64 the problem is still there I'm afraid. Regards, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR
I had a look at the assembler generated by 3.3.1 . # Var uix located in stack [rsp+83240] movl %edx,%eax movq %rax,83280(%rsp) # Var AttackLoc *located in stack [rsp+83280]* # [503] var . # [587] TestLoc := AttackLoc; *movl 83280(%rsp),%r14d* # <<-- # Var AttackLoc *located in register r14d* movl %r14d,24(%rsp) . AttackLoc location is changed to a register as before, but here it is actually moved with a movl. It seems the bug is caused by the absence of this movl instruction. Cheers, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR
Its looking like it was fixed in main somewhere between 31cd3df7 24 Jan, 2021 & 837b433a 28 Apr, 2021 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR
On 12/03/2022 11:33, Florian Klämpfl via fpc-pascal wrote: Am 12.03.2022 um 12:05 schrieb Peter via fpc-pascal : Its looking like it was fixed in main somewhere between 31cd3df724 Jan, 2021 & 837b433a28 Apr, 2021 Can you bisect it by any chance? See https://wiki.freepascal.org/FPC_git#bisect.27ing ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Hi Florian, The problem was fixed with commit 503fc85d 2021-04-06 florian * patch by J. Gareth Moreton: handle register allocations correctly in MovMov2Mov 3, resolves #38703 https://gitlab.com/freepascal.org/fpc/source/-/issues/38703 Assembler for line 587 and surrounding comments from previous commit # Peephole Optimization: MovMov2Mov 3 done # Peephole Optimization: MovMovMov2MovMov 1 done # [587] TestLoc := AttackLoc; movl 83288(%rsp),%eax # Var AttackLoc located in register r13d movl %eax,24(%rsp) # Peephole Optimization: MovxMov2Movx From commit 503fc85d 2021-04-06 # Peephole Optimization: MovMov2Mov 3 done # [587] TestLoc := AttackLoc; movl 83288(%rsp),%r13d # Var AttackLoc located in register r13d # Peephole Optimization: MovMov2MovMov1 done movl %r13d,24(%rsp) In this example, although the compiler intends to use r13d for the parameter AttackLoc from line 587 onwards, it does not actually load that register, prior to fix for #38703 Cheers, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR
On 13/03/2022 18:19, Florian Klämpfl via fpc-pascal wrote: Thanks for tracking this down! I have cherry picked the commit to fixes. Great! It was a nasty bug. Good to see it fixed for the next release. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR
On 14/03/2022 06:59, Sven Barth via fpc-pascal wrote: Peter via fpc-pascal schrieb am So., 13. März 2022, 22:58: On 13/03/2022 18:19, Florian Klämpfl via fpc-pascal wrote: > Thanks for tracking this down! I have cherry picked the commit to fixes. Great! It was a nasty bug. Good to see it fixed for the next release. Would you please check whether it's indeed fixed with 3.2.3 now? Just in case the fix relied on something else... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal Hi Sven, I have checked with 3.2.3 and its fixed. Cheers, Peter ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Broken code with PEEPHOLE & REGVAR
Testing 3.2.3 on Arch Linux # [584] if not AttackPositionReached then testb %r15b,%r15b je .Lj270 # [587] TestLoc := AttackLoc; movl 83288(%rsp),%r13d # <- *** # Var AttackLoc located in register r13d movl %r13d,24(%rsp) # [591] NextLoc := PreLoc[TestLoc]; ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
