[fpc-devel] Is that valid? property using function with extra args...

Below compiles (3.2.3). Should it? Note the extra argument in "GetFoo". It only works because it has a default. program Project1; type   tf = class   private     function GetFoo(AIndex: Integer; b: integer = 2): char;   public     property Foo: char index 1 read GetFoo;   end; function tf.GetFo

Re: [fpc-devel] Maybe room for better documentation? open array as var param

On 20/07/2023 18:41, Martin Frb via fpc-devel wrote: For const param, it is well documented that the value (that includes the variable that is passed) must not be changed. But for "var param"? Actually my previous example was not even the generic case. Passing any variable that is allocated

[fpc-devel] cthreads and fpc.cfg?

Using 33dba315366ec3002e062c3aa6dcb15b88356580 (3.3.1) My fpc.cfg looks like this / any idea?: Threading has been used before cthreads was initialized. Make cthreads one of the first units in your uses clause. ___ fpc-devel maillist - fpc-devel@li

Re: [fpc-devel] threads vs widestringmanager / crash

Ok, I don't know too much about the whole initialization But on the off chance of triggering some ideas, I throw in a couple of my thoughts On 19/12/2022 07:42, Sven Barth wrote: Am 07.07.2018 um 15:04 schrieb Martin: So (guessing) the original issue may be due to the debugger. The de

[fpc-devel] InitHeap in TLS_Callback [[Re: threads vs widestringmanager / crash]]

On 20/12/2022 15:08, Martin wrote: Ok, I don't know too much about the whole initialization But on the off chance of triggering some ideas, I throw in a couple of my thoughts On 19/12/2022 07:42, Sven Barth wrote: This is likely to be the cause, cause the EXEC_TLS_CALLBACK is execut

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

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). But it then

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

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

[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 trunk/install/binw64/objdump.ex

[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 80386,

[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? https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-getcharacterplacementw

[fpc-devel] TThread.RemoveQueuedEvents

Wath is in the following indented? The doc says https://www.freepascal.org/docs-html/rtl/classes/tthread.removequeuedevents.html all calls to the given method are removed. However there may be more than one way to read this. aMethod: TThreadMethod

[fpc-devel] Warning: Unicode constant cast with potential data loss

FPC 3.2.0 var   u,u2 : UTF8String; begin   u := #$2267'x';   u2 := #$2267;  // warning Assigning a WideString to a Utf8String works without warning. Assigning a WideChar (2nd line) to a Utf8String causes "Warning: Unicode constant cast with potential data loss" Apparently it is first convert

[fpc-devel] WriteBarrier

Ok, I got a bit further. Assuming the following  (and not counting on Interlocked... doing any Barriers itself) Thread 1   Foo := val; // normal assign   WriteBarrier; // make sure above write to Foo is executed, before the next write to flag   InterLockedIncrement(Flag);  // needed for the loc

[fpc-devel] TThread.Terminate;

procedure TThread.Terminate; begin   FTerminated := True; end; Should that not in some way deal with memory barriers? E.g. InterlockedExchange or similar? And the same for the "Terminated" property, should that have a getter to do the same? As it stands, afaik a thread could get the "Termin

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

I am tracing a race condition in lazCollections TLazThreadedQueue on win-64 What is supposed to happen in the following case: 2 or more threads are waiting on the some event   RTLeventWaitFor(UniqueEvent) 1 thread sets it   RTLeventSetEvent(UniqueEvent) I expect that wakes up exactly ONE threa

Re: [fpc-devel] strange (?) "result not initialized"

Another strange "not inline warning" All marked as inline Implementation code of Some is first, then Bar, then FOo. So all code is known,when needed. Foo => Bar => Some Bar compiles without warning. So I guess Some was inlined Foo gives a warning. But it warns that "Some is not inlined" Does

[fpc-devel] strange (?) "result not initialized"

In the code below / with fpc 3.2 function TDwarfInformationEntry.ReadName(out AName: PChar): Boolean; var   AttrData: TDwarfAttribData; begin   PrepareAbbrev;   if dafHasName in FAbbrev^.flags then begin     Result := GetAttribData(DW_AT_name, AttrData);     assert(Result and (AttrData.Informatio

[fpc-devel] Dwarf and "Result"

I just noted (testing with 3.3.1 from 2 or 3days ago) that -gw adds 3 variables for result "result" "FUNCTIONNAME" "RESULT" Why an upper, and lowercase result? Not tested with dwarf-3 Not tested with older fpc Win64 Regards Martin ___ fpc-devel mai