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

[Martin via fpc-devel]

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.GetFoo(AIndex: Integer; b: integer): char;
begin
end;

begin
end.


-
On that note,
if instead the correct amount of params was given:

    function GetFoo(AIndex: Integer= 2): char;

But with a default, should that work.
It does, and IMHO it is ok to work.

If used by the property, then a value is always given and the default 
never matters.

But if called directly, the default can be used.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Dwarf and "Result"

[Martin via fpc-devel]

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 maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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.InformationEntry = Self), 
'TDwarfInformationEntry.ReadName');

    Result := ReadValue(AttrData, AName);
  end
  else
  if (dafHasAbstractOrigin in FAbbrev^.flags) and PrepareAbstractOrigin 
then
    Result := FAbstractOrigin.ReadName(AName)    // 
<<<

  else
    Result := False;
end;

components\fpdebug\fpdbgdwarfdataclasses.pas
line 2875

The indicate line says "fpdbgdwarfdataclasses.pas(2870,30) Warning: 
Function result variable does not seem to be initialized"

And I get the warning 5 times.

I also get one (just one) such warning on:
- the "begin" line of the function
- the "PrepareAbbrev" line (which is a call to a procedure)

This appears to be, due to the function being marked "inline".
If I remove the "inline" then the warning goes.

---
Unrelated:

I also get the obvious
fpdbgdwarfdataclasses.pas(2887,30) Note: Call to subroutine "function 
TDwarfInformationEntry.ReadName(out AName:PChar):Boolean;" marked as 
inline is not inlined


Of course a call to the function itself is not inlined.
(Well yes, it could be a few times, like loop unroll / but does that 
warrant a warning?)

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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 that mean, that Bar got inlined in Foo, but that it was not the Bar 
that inlined Some, but a Bar that did not?


No problem, if the compiler would decide to inline / not inline in 
whatever way.
But maybe if the message is referring to such nested warnings, then it 
should indicate that?




real code is
function TDwarfInformationEntry.IsAddressInStartScope(AnAddress: 
TDbgPtr): Boolean;


at svn rev 63798
there may be changes in later rev.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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 thread (never mind wich)?
Or ALL?

If no one resets the event (NO call to RTLeventResetEvent), then that 
does not change anything? It is still just the one thread that got woken up?


Thanks for any feedback
Martin


p.s.
Background

TLazThreadedQueue.PopItem works like this

EnterCritical
  If item avail then return item
ExitCritical
   // race condition between those lines.
RTLeventWaitFor(itemAdded)
EnterCritical
  If item avail then return
ExitCritical

If 2 or more reading (popping) threads are both at the indicated location,
and if during this time 2 or more items are added
then there is a problem (I believe)

adding (pushing) an item does
  RTLeventSet(itemAdded)
adding 2 items (with no pop in between) calls Set twice
   => 
https://lazarus-ccr.sourceforge.io/docs/rtl/system/rtleventsetevent.html

    It is unclear if the 2nd RTLeventSet has any effect ?


According to my tests:
- I "sleep()" 2 listeners at the critical line, so they both will 
WaitFor after the sleep
- while they sleep I add 2 items (2 calls to RTLeventSet, no one 
listening yet)

- Both start RTLeventWaitFor
  => only one listener wakes up.
Is that the expected behaviour?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] TThread.Terminate;

[Martin via fpc-devel]

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 "Terminate" flag with an 
unknown delay?


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] WriteBarrier

[Martin via fpc-devel]

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 lock, if others do 
write access too.


Thread 2
  If InterLockedExchangeAdd(Flag, 0) > 0 then begin
     ReadBarrier; // make sure below read is executed only after the 
read of the flag

 myval := Foo;
  end;

That should get the correct value of Foo.
Even if run a million times, and in all of this the read of Flag 
eventually happens exactly one cpu cycle after it was set.



Now the Examples I've seen all are showing cases where the re-orderable 
assignment are in close proximity to each other.
On the other hand compiler and CPU are getting better and better. So 
there is nothing that would in theory stop them to swap read/write order 
over any amount of statements


So even if (in Thread 1) I returned from a subroutine (which could be 
inlined for all I (don't) know), done some other work, and only then set 
the flag.
If I want to be sure, any value that was written in the subroutine is 
written before the flag gets set, then I should do a WriteBarrier?

Or is that paranoid?


Thanks again
Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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 converted to a char in the System codepage, and 
then to string.


Is that intended?

Actually if
  u: AnsiString

then the result is '??' (so data is lost), yet no warning.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] TThread.RemoveQueuedEvents

[Martin via fpc-devel]

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 


is "procedure of object"

The method "aMethod" (which is what is given) therefore consists of 
proc-address and instance-address.


However the code actually removes all methods at proc-address, 
regardless of the instance.


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"
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] declaration of GetCharacterPlacementW(

[Martin via fpc-devel]

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 maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

- 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, version 1 (SYSV), statically linked, with debug_info, not stripped




But then
/home/m/fpc/rel_3.2.0/source/compiler/ppc386 fpmake.pp 
-Fu/home/m/fpc/rel_3.2.0/source/packages/fpmkunit/units_bs/i386-linux 
-Fu/home/m/fpc/rel_3.2.0/source/rtl/units/i386-linux  -gw -O-1

/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -ldl
/usr/bin/ld: cannot find -lc




I do have (which I guess is the lib in question?)

file /lib/libpthread.so.0
/lib/libpthread.so.0: symbolic link to libpthread-2.32.so

file /lib/libpthread-2.32.so
/lib/libpthread-2.32.so: ELF 32-bit LSB shared object, Intel 80386, 
version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, 
BuildID[sha1]=32aaf5acc1c589123b059f4e74cc30b69be2c628, for GNU/Linux 
3.2.0, not stripped



I also tried to find any other potential dependency To no avail yet.
such as
 glibc-2.32-2.fc33.i686 => installed
 clthreads.i686 => installed (the only reasonable close match that came 
up searching for thread)


Any ideas?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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.exe  can not correctly 
read it, lines and addresses are there, but filenames/dir are empty.

gdb has issues too.
___
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!

[Martin via fpc-devel]

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

Below output is 64 bit Ubuntu Linux.

Is this of interest?
If yes, what info will be needed?


utils/digest output/x86_64-linux/log
No run found for "Skipping test because for other target 
webtbs/tw36544b.pp 2020/01/10 16:39:20"

Total = 7885 (23:7862)
Total number of compilations = 4857 (12:4845)
Successfully compiled = 3676
Successfully failed = 1169
Compilation failures = 8
Compilation that did not fail while they should = 4
Total number of runs = 3028 (11:3017)
Successful runs = 3017
Failed runs = 11
Number units compiled = 152
Number program that should not be run = 492
Number of skipped tests = 512
Number of skipped graph tests = 10
Number of skipped interactive tests = 31
Number of skipped known bug tests = 7
Number of skipped tests for other versions = 4
Number of skipped tests for other cpus = 270
Number of skipped tests for other targets = 190
make[1]: Leaving directory '/home/m/fpc/rel_3.2.2/source/tests'


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[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?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] function GetCurrentThreadId vs variable ThreadID

[Martin via fpc-devel]

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 maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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 may not be correct (not sure, but read my big comment on the issue)

While -O2 is normally not for debugging, it may still be desirable that 
debug info is at least conform to the DWARF standard.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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 attempts
   DW_OP_push_object_address, DW_OP_deref
which may not be correct (not sure, but read my big comment on the issue)

While -O2 is normally not for debugging, it may still be desirable 
that debug info is at least conform to the DWARF standard.


Looking at GDB.

From what I can see, current gdb (git main) fails in the IDE, on the 
"ptype s", because the upper bound is expected to be a constant, but it 
is not. (gdb bug)

Outside the IDE "p S" returns without error, but empty result.


I looked at the code "expr.c"
DW_OP_deref will always call
        this->read_mem (buf, addr, addr_size);

So even if it gets a value from the register, gdb (most likely) would 
not take the register content as the deref value, but deref it again.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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 may not be correct (not sure, but read my big comment on the issue)

While -O2 is normally not for debugging, it may still be desirable that 
debug info is at least conform to the DWARF standard.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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 
executed by Windows for every thread that is started for an 
application. And if the debugger triggers the start of a thread...


Maybe, maybe not always? But, yes at least in the case that I 
documented in 2018: 
https://lists.freepascal.org/pipermail/fpc-devel/2018-July/039374.html


While I just looked through that code, I came to think there may be yet 
another issue.


If a thread is started, that can call EXEC_TLS_CALLBACK.
And EXEC_TLS_CALLBACK  can call InitHeap (in DLL_PROCESS_ATTACH) before 
the main thread has run InitHeap.


But InitHeap does not seem to be threadsafe.

InitHeap itself does probably work if it runs overlapping. But, if one 
thread already goes into using the heap (e.g. allocating) while the 
other still is in InitHeap... That likely does not go well.


___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Martin via fpc-devel]

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 
debugger interrupts the target early on. And that does create a 
thread in the target.
If such an external thread happens, would fcp execute the code in 
question?


This is likely to be the cause, cause the EXEC_TLS_CALLBACK is 
executed by Windows for every thread that is started for an 
application. And if the debugger triggers the start of a thread...


Maybe, maybe not always? But, yes at least in the case that I documented 
in 2018: 
https://lists.freepascal.org/pipermail/fpc-devel/2018-July/039374.html


Yet in the system unit:

initialization
.
  if not Assigned(CurrentTM.BeginThread) then
  begin
    InitHeap;
    InitSystemThreads;
  end;
  SysInitExceptions;
  initunicodestringmanager;
  InitWin32Widestrings;

So the WS-Mgr is only assigned after InitSystemThreads => which sets up  
RelocateThreadVar => which can call InitThread.


So order may need to be changed there (if that is possible).
Of course, the case where EXEC_TLS_CALLBACK calls InitThread remains.

A lot of the WS-Mgr init is assigning pointers to the correct procedure.
So if InitThread sees that this has not been done yet, InitThread could 
call those.
Even if 2 threads (main and the early thread) both assign values to the 
pointer, they assign the same value, and so that should not do harm.
Of course the thread init must not change the value, once it was set by 
the main thread, in case usercode assigned a diff value (so maybe in 
ThreadInit, use Interlocked)


This may mean to break "InitWin32Widestrings" into 2 parts, because it 
also prepares some tables.

But those are not needed for "GetStandardCodePageProc"

So if the setting of the codepage related proc pointers are moved to a 
separate init-method, then that can be called (if needed) by InitThread.


--
Or maybe if EXEC_TLS_CALLBACK calls InitThread, it can do the (partial) 
init of WidestringMgr before? (if the order in the initialization 
section can be changed to do the same?)


--
I am not sure if this code needs to worry about any of the other WS-Mgr 
functions.
Any thread that early is not started by Pascal code (neither user, nor 
rtl). It will be a thread working some kernel proc. And that shouldn't 
access the WS-Mgr?



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] cthreads and fpc.cfg?

[Martin via fpc-devel]

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

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

[Martin via fpc-devel]

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 on the Heap (a field of an 
instance, an element of an array) as a "var param" has the danger that 
it can be freed.


And yes, it should be obvious. If you intent to write to a variable, you 
must not destroy it.
However, you must also be aware, that in case of an array, if you just 
resize it, it may move => yet your var param will not follow that move.


I think it may be "interesting" enough to deserve a small note.

--
The below should brinte 200 to 209.
But it does print a 999 in the middle.




program Project1;
{$mode objfpc}

var x,y: array of integer;
  i: Integer;

procedure foo(var a: integer);
var
  j: Integer;
begin
  x := nil;
  SetLength(y, 10);
  for j := 0 to 9 do y[j] := 200+j;

  a := 999;
end;

begin
  SetLength(x, 10);
  for i := 0 to 9 do x[i] := 100+i;
  foo(x[5]);
  for i := 0 to 9 do writeln(y[i]);
  readln;
end.

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel