Re: [fpc-devel] TDateTime issue.

[Marco van de Voort via fpc-devel]

Op 01/04/2024 om 17:23 schreef Werner Pamler via fpc-devel:
Yes, you are right. Now I see that it works, after updating my fixes 
(which I should have done earlier).


Rule of thumb, I merged most fixes in December, except 
fcl-web/passrc/json/pas2js and some associated packages. Some later revs 
of the system.ioutils etc units were also intertwined with them.


Merging them was the core goal for me, so that Lazarus could start to 
use them with FPC 3.4.0 (since then one release back would have been 
3.2.4 that had them)


I wanted the begin merging the remaining ones too, but Florian planned 
to release quickly (but was later thwarted by some arm-linux linking 
issues that are still pending)


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

Re: [fpc-devel] TDateTime issue.

[Marco van de Voort via fpc-devel]

Op 01/04/2024 om 12:30 schreef Werner Pamler via fpc-devel:

Am 31.03.2024 um 11:55 schrieb Pascal Pype via fpc-devel:

There seems to be a bug in the TDateTime data type. When the time
difference between two TDateTime variables is just one millisecond, the
compareDateTime function returns 0 (equality) rather than the expected
-1 or 1 (different).


It is fixed in FPC/main (probably in commit 
492a0ffcac7035e9f096e353db41bacabedcc91d), not yet in Fixes. Marco, 
shouldn't this be back-ported?





The below revision is marked as merged

*492a0ffcac7035e9f096e353db41bacabedcc91d 
* 
michael Sun Jun 20 08:00:01 2021 r49517 -


* Better precision for samedatetime. Issue ID 0039023 
, patch by Zoran Vučenović
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TDateTime issue.

[Marco van de Voort via fpc-devel]

Op 31/03/2024 om 11:55 schreef Pascal Pype via fpc-devel:
  
My freepascal version is: 3.0.0.

The platform is: Slackware 14.2 x86_64.


Please try a more recent version (and preferably even the fixes version 
via FPCDELUXE). Datetime support has detail fixes every release, and 
3.0.0 is 9 years old.


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

Re: [fpc-devel] defines by the compiler... / linux, LIBC, SysCall

[Marco van de Voort via fpc-devel]

Op 11-1-2024 om 16:56 schreef Martin Frb via fpc-devel:

On 11/01/2024 16:34, Marco van de Voort via fpc-devel wrote:


Op 11-1-2024 om 15:48 schreef Martin Frb via fpc-devel:

- Can (on any linux/unix)  "uses SysCall" be compiled  (without error)


You can test that yourself on a Linux system by compiling a cycle 
with -dFPC_USE_LIBC and then compiling a test program (without 
defines)   Since there was a bugfix necessary, I assume not.


Not necessary. (as far as I understand the comments that had been made 
already)
-dFPC_USE_LIBC  would not change the os target to sunos.  And 
therefore FPC would not look at the tsysteminfo 


Let me state it more clearly:

The point is that given a precompiled Linux RTL, to my best knowledge  
you can't test any define outside the FPC build environment to see if 
the RTL was compiled with FPC_USE_LIBC or not. Maybe there is some 
workaround testing for some symbol inside the system unit with{$if 
defined(symbol}, but there is no supported global define to test.


Targets that enable libc by default (darwin, sunos and openbsd 
apparently) by default make this work by locally enabling FPC_USE_LIBC, 
usually both in rtl/$target or by other hacks in various packages/ dirs 
for shared code, and simply not providing any alternative in the target 
specific code.


And to my best knowledge the "LIBC" in the extradefines of Slowaris 
(below) means zip, nada, zilch. It is an artifact of 1.0.x times, which 
is so old EVEN Lazarus doesn't support it :-)



containing
     extradefines : 'UNIX;LIBC;SUNOS;HASUNIX';

-dFPC_USE_LIBC   would just affect the "uses SysCall" (and that 
hopefully in *exactly* the same manner as compiling on sunos)



Yes. Inside the FPC build process. And is always undefined outside of it.



- Does it need to be guarded {$IFnDEF LIBC} ?


That define would be FPC_USE_LIBC.  But afaik that is only defined ad 
hoc on spots where it is needed during the FPC compilation. I.e. it 
is set in the build system rather than being a compiler built in. So no.


Sure?

-dFPC_USE_LIBC    would be specified be the user or Makefile when the 
fpc/rtl is build.


Yes. But the targets that default to it locally define it in RTL 
makefiles and $ifdef code. Not by means of compiler.




But when an fpc (that had been build with -dFPC_USE_LIBC ) is used to 
compile a random project, will then this fpc by tiself define 
-dFPC_USE_LIBC    (without the user needing to do so?)


Not that I know. Which code does this according to you? The whole 
compiler/ dir doesn't grep on FPC_USE_LIBC so how would this happen?



I have 2 different concerns

1) What happens on sunos?
(Where the compiler defaults to LIBC)

That is the case I wont to cover.


Currently the assumption is that you simply test for such targets and 
then define FPC_USE_LIBC yourself for where you need it.  Any additional 
testing of system or syscall with some $if defined would be nice, but 
beware of multiplatform concerns.




2) What happens, if the user "tampers" with settings building a non 
default fpc.


If people do unsupported things they (and apparently you)  are f*scked.



That 2nd part is not that important in respect to my questions in this 
mail.

If the user does that, then  (when compiling lazarus or any project)
-  no special define may be set by FPC (and that is ok)
- the user may have to set a define according to the project (lazarus 
could offer a workaround define)


openbsd seems to use FPC_USE_SYSCALL as a workaround to override a 
locale FPC_USE_LIBC ( packages rtl-extra/bsd/osdefs.inc)


So openbsd locally defines FPC_USE_LIBC if "openbsd" is defined, but NOT 
if FPC_USE_SYSCALL is defined, while a hack, it has a certain symmetry.



-
as for point 1
To make sure it compiles with
- normal build fpc on linux/darwin
- normal build fpc on sunos


{$ifdef linux}
or other "full"syscall  *nix ports like FreeBSD and NetBSD and OPENBSD 
with FPC_USE_SYSCALL.

   uses   SysCall;
{$endif}
{$ifdef darwin}


or solaris or openbsd


   {$DEFINE FPDEBUG_USE_LIBC}  // darwin: always libc
{$else}
   {$IF not declared(Do_SysCall)}  // Linux, but no Do_SysCall


But not if trunk ?



     {$IFDEF LIBC}    // Does this define ever exist (by fpc)
   {$DEFINE FPDEBUG_USE_LIBC} // no DoSysCall ==> use libc
     {$ELSE}
   {$DEFINE FPDEBUG_USE_DUMMY}  // no DoSysCall ==> empty dummy proc
     {$ENDIF}

   {$ENDIF}

  // ELSE: Do_Syscall exists and can be used
{$endif}

Will that work?
==>> Will (on linux, including sunos)
  "uses SysCall"
compile (not throw an error during compilation). (that is for NORMAL / 
non-tampered FPC)


If yes, then that should work. (even if LIBC isn't defined)
If yes, then I can check if "DoSysCall" can be used


I don't know. Needs testing on many targets and platforms.

IMHO:

- file a _really_, /really/ urgent bugrepo

Re: [fpc-devel] defines by the compiler... / linux, LIBC, SysCall

[Marco van de Voort via fpc-devel]

Op 11-1-2024 om 15:48 schreef Martin Frb via fpc-devel:


But neither LIBC nor HASUNIX are listed on that page.


I think LIBC as a define is a remnant of a 1.0.x era port and has no 
meaning in 2.0.


This is meanwhile all 20 years ago, so my memory might be a bit hazy 
(christmas 2003 and the half year after that), BUT HASUNIX was iirc 
meant to flag something for partially unixy targets, for which unit 
baseunix could be /mostly/ implemented, but unit unix not.  The only 
usage seems to be in link.pas around a USES baseunix, so I assume it 
means it has at least baseunix (but might not have unit unix or define 
"unix"). Possible candidates for such partial unixy targets are 
QNX,beos+variants and the libc netware ports.


FPC does use  a define FPC_USE_LIBC to switch the RTL to use library 
(libc, or libroot in old BEOS) rather than directly doing syscalls.


FPC_USE_LIBC was originally prepared because some 1.0.x era ports (sunos 
and beos) were libc ports by Carl.


I also used it to troubleshoot issues with the syscall RTL by linking it 
to libc and e.g. s/ktracing it. But then an year later Jonas used it for 
Darwin and massively cleaned it up, and that established it in a more 
permanet way. The way the define is set is a bit inconsistent though:


- The original concept and the way I've always used it as a cycle or 
snapshot (toplevel FPC "make all") options by setting OPT=-dFPC_USE_LIBC


- The targets openbsd and darwin set it in the RTL makefile and various 
ad-hoc looking ifdef/defines in packages/. Quite often using osdefs.inc. 
This is not really nice, as it prohibits the global switching between 
libc/syscalls that was the original idea. However probably the original 
concept was too difficult for targets where FPC_USE_LIBC was default, 
because you always had to pass the define in build commands or put it in 
fpc.cfg), and local workarounds were added.


Similarly I see hasunix defines in the makefiles too, while that is a 
target built-in. Odd.  Probably in the past it had more meaning.




1) I can add "uses SysCall".
There is a comment this will work in 3.3.1 / not sure if 3.2.x will 
abort compile, or just use some unit without the expected symbol.


So the question is (for compilers starting at 3.2.0  // that is one 
version back)


- Can (on any linux/unix)  "uses SysCall" be compiled  (without error)


You can test that yourself on a Linux system by compiling a cycle with 
-dFPC_USE_LIBC and then compiling a test program (without defines)   
Since there was a bugfix necessary, I assume not.



- Does it need to be guarded {$IFnDEF LIBC} ?


That define would be FPC_USE_LIBC.  But afaik that is only defined ad 
hoc on spots where it is needed during the FPC compilation. I.e. it is 
set in the build system rather than being a compiler built in. So no.


You can go two directions:

1 -dFPC_USE_LIBC is considered experimental for  Linux, and simply 
ignore it for old versions.


_OR_

2 for older versions, if the unit directly or indirectly uses packages 
that link to libc (like LCL and thus X11/GTK/QT) , I'd simply always use 
the libc declaration for older versions.




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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Marco van de Voort via fpc-devel]

Op 27/12/2023 om 13:37 schreef Marco van de Voort via fpc-devel:


- The short description in the overview (#rtl) page still doesn't 
appear ,


After some debugging, my guess is that in this specific case the path 
chopping code in TDocNode.CreateChildren at dglobals:455 and further is 
to blame.


The tag gets chopped up, and a node is made with name "system" not 
"system.uitypes"


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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Marco van de Voort via fpc-devel]

Op 26/12/2023 om 19:53 schreef Michael Van Canneyt via fpc-devel:


If you say so.   It is still ambiguous though, even if most common 
cases can disambiguated.   (a.b.c.d is either symbol d in unit b.c  
or field d in structure type c in unit b), which is why I didn't 
favor it.


Can you explain what the exact problem is with system.uitypes other than
that the description file was not included in the build project xml ?


It was that mostly, I retested it, but missed that you hadn't committed 
that.



I built the docs with it and it is as complete as can be expected. All 
works as it is supposed to work, links and all.


But not everything is ok.

- The short description in the overview (#rtl) page still doesn't appear ,

-  the unit description seems to be replaced by some copyright text 
rather than the description in the XML


I'll see if I can play with that.



I removed it again from the build project (commented out the relevant
entries), since the xml file is horribly incomplete, and we only 
include completed units in the docs.


Maybe that is a good  policy in the general case, but with core types as 
TColor and -Rec  that hinders lazarus.






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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Marco van de Voort via fpc-devel]

Op 26/12/2023 om 19:53 schreef Michael Van Canneyt via fpc-devel:


Can you explain what the exact problem is with system.uitypes other than
that the description file was not included in the build project xml ?

I built the docs with it and it is as complete as can be expected. All 
works as it is supposed to work, links and all.


See the link I posted to the daily snapshot. The lemmas of the symbols 
exist but only contain the declaration, no information whatsoever from 
the XML. Not even the short description of the unit on the main contents 
page.


Don mostly clicked through because of the TColor description.

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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Marco van de Voort via fpc-devel]

Op 26/12/2023 om 18:20 schreef Michael Van Canneyt via fpc-devel:


To fix this either we have to e.g. keep a list of packages and a 
list of units and then try to disambiguate to only pick the longest 
match. That maybe have risks that other corner cases be found or 
that the list of units is not yet complete at any point when this 
system is inside fpdoc. This requires no changes to the .xmls


This is the road to take. It's similar to what the compiler does, 
after all.
Not the easiest, not the safest, if at any time during the fpdoc run, 
the complete list of units is available.


The complete list is always available.


If you say so.   It is still ambiguous though, even if most common cases 
can disambiguated.   (a.b.c.d  is either symbol d in unit b.c  or field 
d in structure type c in unit b), which is why I didn't favor it.


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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Marco van de Voort via fpc-devel]

Op 26/12/2023 om 10:29 schreef Michael Van Canneyt via fpc-devel:




To fix this either we have to e.g. keep a list of packages and a list 
of units and then try to disambiguate to only pick the longest match. 
That maybe have risks that other corner cases be found or that the 
list of units is not yet complete at any point when this system is 
inside fpdoc.  This requires no changes to the .xmls


This is the road to take. It's similar to what the compiler does, 
after all.
Not the easiest, not the safest, if at any time during the fpdoc run, 
the complete list of units is available.




A more definitive choice is to change something about the notation 
and somehow replace or escape dots within identifiers. like  
rtl.#system.uitypes#.recordtype.fieldname  or like


The # notation is already taken to indicate a fully qualified name.

At the start yes, I remembed that when I looked in the sources 
yesterday, but another escapes character can be used, it doesn't 
invalidate the principle.
rtl.system#uitypes.recordtype.fieldname or 
rtl.system..uitypes.recordtype.fieldname. (exact characters to be 
used T.b.d.    Only requires changes to the XML for dotted unit names.


and everything referring to it since any cross-reference would also 
need to be changed.


True, but how many references are there already to dotted units? Not yet 
that much. It looked me the easiest short term doable one.



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

[fpc-devel] fpdoc path + system.uitypes problems.

[Marco van de Voort via fpc-devel]

(forum thread: 
https://forum.lazarus.freepascal.org/index.php/topic,65629.0.html)


Don noticed that the system.uitypes lemma's in the CHM are empty, both 
with 3.2.x as 3.3.x fpdoc.


I checked the only html snapshot and it is the same: 
https://www.freepascal.org/daily/doc/rtl/system.uitypes/index-5.html


I can remember that I tried to debug this a while back, and that this is 
a fundamental problem of fpdoc because it uses dots to separate the 
parts of a lemma. (e.g. packagename.unitname.recordtype.fieldname).  
Separating a path on dot then breaks the unit name. If unit name is 
system.uitypes.somevariable, it tries to find symbol uitypes in system, 
and then searches for a  field in somevariable  etc.


To fix this either we have to e.g. keep a list of packages and a list of 
units and then try to disambiguate to only pick the longest match. That 
maybe have risks that other corner cases be found or that the list of 
units is not yet complete at any point when this system is inside 
fpdoc.  This requires no changes to the .xmls


A more definitive choice is to change something about the notation and 
somehow replace or escape dots within identifiers. like  
rtl.#system.uitypes#.recordtype.fieldname  or like 
rtl.system#uitypes.recordtype.fieldname or 
rtl.system..uitypes.recordtype.fieldname. (exact characters to be used 
T.b.d.    Only requires changes to the XML for dotted unit names.


Opinions etc ?



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

Re: [fpc-devel] AdjustLineBreaks: fixed in trunk, broken in fixes_3_2 (?)

[Marco van de Voort via fpc-devel]

Op 17-12-2023 om 17:49 schreef Marco van de Voort via fpc-devel:


Op 17-12-2023 om 17:27 schreef Bart via fpc-devel:
  I would request that the changes from commit 1c4151d8 are merged to 
fixes_3_2.


I'm currently trying to make a dent in the merging backlog that the 
transition to git made.


I'm trying to merge as much as possible in order, and this one still 
doesn't merge cleanly, so it will have to wait till I'm a further in 
the merge process.


Never mind, it is merged. The road blocks turned out to be  in the 
dotted RTL related revisions (since it is a pchar based routine), so in 
the end I manually merged.


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

Re: [fpc-devel] AdjustLineBreaks: fixed in trunk, broken in fixes_3_2 (?)

[Marco van de Voort via fpc-devel]

Op 17-12-2023 om 17:27 schreef Bart via fpc-devel:
  
I would request that the changes from commit 1c4151d8 are merged to fixes_3_2.


I'm currently trying to make a dent in the merging backlog that the 
transition to git made.


I'm trying to merge as much as possible in order, and this one still 
doesn't merge cleanly, so it will have to wait till I'm a further in the 
merge process.


If it is not merged a week from now, remind me again.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)

[Marco van de Voort via fpc-devel]

Op 14-12-2023 om 21:27 schreef Martin Frb via fpc-devel:


I am actually pretty sure, on Linux, I can get what I want by doing it 
in the "OnFork" event of TProcess.
But on Windows it is well hidden away in the "Execute" method, nothing 
virtual that could be intercepted.


Change the input handle and use popassinput ?

But I wonder if this is not too specialistic. It depends on how well you 
can abstract it into TProcess, and preferably in a somewhat similar way 
for all OSes.

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

Re: [fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)

[Marco van de Voort via fpc-devel]

Op 14-12-2023 om 20:29 schreef Martin Frb via fpc-devel:

 Op 14-12-2023 om 17:30 schreef Martin Frb via fpc-devel:
If I am right the TProcess currently does not allow redirection of 
StdOut/In to/from a file (or other handle provided).


It does, if you need a runcommandloop like routine that writes to 
file. Partially this can be even simplified by inheriting TProcess 
and overriding readinputstream
But that means the parent process has to read the data (from the file) 
and forward it.


Without a shell that always needs to happen. How else ? Keep in mind 
that TProcess is a kernel and not a shell level concept.



Also not sure how to simulate an EOF in that case


Probably close the pipe.

Anyway the full project is here: 
http://www.stack.nl/~marcov/files/processmemodemo.zip


It is slightly different, a TProcess based application that tries to 
instrument a secondary binary.



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

Re: [fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)

[Marco van de Voort via fpc-devel]

Op 14-12-2023 om 17:30 schreef Martin Frb via fpc-devel:
If I am right the TProcess currently does not allow redirection of 
StdOut/In to/from a file (or other handle provided).


It does, if you need a runcommandloop like routine that writes to file. 
Partially this can be even simplified by inheriting TProcess and 
overriding readinputstream



If it does, and I have been missing the "how to", then please 
enlighten me and disregard the remainder of the mail.


The piping to memo (afaik since 3.2.0 or 3.0.4) should be analogues, you 
just need functions to write to disk, see e.g.


https://forum.lazarus.freepascal.org/index.php/topic,42385.msg443351.html#msg443351



Is this something that should be added? (I.e. a feature request to be 
added)
If yes, should there just be 3 properties for the handles? A callback 
to create/provide them? A virtual method?

Should there be a flag?

Maybe you can create a predefined derivative that does this with less 
additional code, but this should already be possible.



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

Re: [fpc-devel] vargars vs array of const for WinAPI

[Marco van de Voort via fpc-devel]

Op 9-11-2023 om 20:47 schreef Martin Frb via fpc-devel:
I saw that in some places (I think gtk2) "varargs" is used for open 
arrray API calls.


Any reason that is not adapted for Windows (overloaded)?


It probably is newer (kylix). I'm not sure anyway what the problem is? 
Why would varargs be better



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

Re: [fpc-devel] About the var param in CreateConsoleScreenBuffer

[Marco van de Voort via fpc-devel]

Op 9-11-2023 om 20:43 schreef Martin Frb via fpc-devel:

On 09/11/2023 14:19, Marco van de Voort via fpc-devel wrote:


Anyway, standard procedure in such cases is to move the pascallized 
declaration to redef.inc and have a pointer value in the original 
place. Which I just commited to GIT.


Thanks. Merge-able?
I usually review my own commits every couple of months, or when a branch 
of a release is imminent.

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

Re: [fpc-devel] About the var param in CreateConsoleScreenBuffer

[Marco van de Voort via fpc-devel]

Op 9-11-2023 om 13:59 schreef Martin Frb via fpc-devel:

Fpc defines
function CreateConsoleScreenBuffer(dwDesiredAccess:DWORD; 
dwShareMode:DWORD; var lpSecurityAttributes:SECURITY_ATTRIBUTES; 
dwFlags:DWORD; lpScreenBufferData:LPVOID):HANDLE; external 'kernel32' 
name 'CreateConsoleScreenBuffer';


`lpSecurityAttributes` is a `var` param in the above. But 
https://learn.microsoft.com/en-us/windows/console/createconsolescreenbuffer 
states that the param is optional and can be null/nil.

var param don't accept nil. So this should be a pointer instead.


Seems so yes.



Yet,  this was reported in 
https://gitlab.com/freepascal.org/fpc/source/-/issues/5836

That issue got closed "*Fixed in version:* 1.9.9"
Only "git blame" shows no change to that line ever. (Well afaik some 
commits are not in git, so could be).


So the question is: Was it fixed and broken again? Was it fixed but 
not committed?


No idea. Annotating revisions in the bugtracker mostly only happened 
with SVN, and afaik this is still CVS era  (?)


Anyway, standard procedure in such cases is to move the pascallized 
declaration to redef.inc and have a pointer value in the original place. 
Which I just commited to GIT.



Or does the cryptic comment


Pascal CONST can be both by reference (thus consuming a *) or by value.

This is the only safe way.


mean its a "wont fix" ?
And if that is the case, then what does this comment mean?

I think that hints on C const and pascal const not necessarily matching. 
(i.e. pre CONSTREF), and using VAR instead. Possibly read over the NIL 
passing bit.

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

Re: [fpc-devel] fnmatch (linux), where is the external

[Marco van de Voort via fpc-devel]

Op 17-10-2023 om 13:17 schreef robert rozee via fpc-devel:

Date: Tue, 17 Oct 2023 09:32:16 +0200
From: Marco van de Voort 

- without the patches you are reviewing it works all fine, suggesting a
problem in those patches that somehow forces linking to the symbol
without it being used.


and installed the three packages (fpc-laz, fpc-src, lazarus-project) as per 
instructions. this gives a completely unpatch, unadulterated 64-bit Linux, 
running a completely unpatch, unadulterated FPC and Lazarus.


And that works.


(1002) Target OS: Linux for x86-64
(3104) Compiling project1.lpr
(10001) PPU Loading 
/usr/share/lazarus/2.2.6/lcl/units/x86_64-linux/gtk2/gtk2int.ppu
(10011) PPU Source: gtk2int.pas not found
(10011) PPU Source: gtk2defines.inc not available
(10011) PPU Source: gtk2winapih.inc not available
(10011) PPU Source: gtk2lclintfh.inc not available
(10011) PPU Source: gtk2listslh.inc not available
(10011) PPU Source: gtk2widgetset.inc not available
(10011) PPU Source: gtk2winapi.inc not available
(10011) PPU Source: gtk2lclintf.inc not available
(10011) PPU Source: gtk2listsl.inc not available
(10028) Recompiling Gtk2Int, checksum changed for 
/usr/lib/fpc/3.2.2/units/x86_64-linux/gtk2/gtk2.ppu
/usr/share/lazarus/2.2.6/lcl/units/x86_64-linux/gtk2/gtk2int.ppu:gtk2int.pas(14,36)
 Fatal: (10022) Can't find unit Gtk2Int used by Interfaces


This is not a linking error or mis-resolved symbol or something similar. 
It is about incrementally rebuilding the LCL automatically as a 
dependency of your project after


(1) installing a new compiler, possibly erasing a release (-Ur) compiler 
with one that isn't.


(2) modifying LCL source.

Which is not _that_ surprising as you leave a lot of state behind from 
your earlier compilation. A Lazarus developer might give you some tips 
on that how to do this more systematic.  I usually first build lazarus 
with make bigide and then with lazbuild (to reenable packages) after 
such mods.


Another, simpler thing might be to simply erase all .o and .ppu from the 
lazarus repo before doing the lazbuild. That erases state (that 
hopefully will then be rebuilt in a consistent way by lazbuild)



reversing the edit, rebuilding the compiler, RTL, etc, and now when run 
lazbuild reports:


This seems to indicate the cause of the state problem is the source 
modification rather than the compiler recompile. Which is logical since 
it invalidates the RTL.



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

Re: [fpc-devel] fnmatch (linux), where is the external code/symbol located?

[Marco van de Voort via fpc-devel]

Op 16-10-2023 om 17:03 schreef robert rozee via fpc-devel:

function fnmatch( ... ) ... external;
function fnmatch( ... ) ... external 'libc';

both yield a compiler that, while capable of compiling a working terminal application, can NOT 
compile a (gtk2) GUI application. so the symbol "fnmatch" is NOT resolving to a match in 
"libc.so.6" where one would normally expect to find fnmatch defined.

many thanks for any help that can be offered...


See the discussion on the forum.

Summary:

- the compiler doesn't link anything with GTK2 or libc for that matter, 
so working compiler or not shouldn't depend on a symbol in GTK2 header.


- Since it has perfectly fine definition in libc, my guess that this is 
some old workaround of GTK2 for some defunct version (or multiple 
varying prototypes) of fnmatch, something might have been resolved a 
decade ago already.


- the symbol is never used in Lazarus to my best knowledge. Simply 
omitting the line from the GTK2 header should allow you to continue with 
your patch evaluation.


- without the patches you are reviewing it works all fine, suggesting a 
problem in those patches that somehow forces linking to the symbol 
without it being used.

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

Re: [fpc-devel] LEA instruction speed

[Marco van de Voort via fpc-devel]

Op 10-10-2023 om 11:13 schreef J. Gareth Moreton via fpc-devel:

Thanks Tomas,

Nothing is broken, but the timing measurement isn't precise enough.

Normally I have a much higher iteration count (e.g. 1,000,000), but I 
had reduced it to 10,000 because, coupled with the 1,000 iterations in 
the subroutines themselves, would have led to 1,000,000,000 passes and 
hence would take in the region of five to ten minutes to complete for 
a 16 MHz 386, for example.  Rika's suggestion of running as many 
iterations as needed until, say, 5 seconds elapses, would help but the 
timing measurements would cause a lot of latency and will be imprecise 
on very slow routines.  Still, let's see if 100,000 gives better 
results for you.



I had the same problem, and now it is stable  Ryzen 5700X (ZEN3)

   Pascal control case: 0.7 ns/call
 Using LEA instruction: 0.4 ns/call
Using ADD instructions: 0.7 ns/call

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

Re: [fpc-devel] make OPT= OPTFPC= NEWOPT=

[Marco van de Voort via fpc-devel]

Op 6-10-2023 om 14:28 schreef Martin Frb via fpc-devel:

What is the difference between those 3?


OPT= always to my best knowledge

NEWOPT is opt only for later cycles and the rest, iow not for the first 
FPC bootstrap cycle (that might be started with an older compiler 
version).  So it is for additional options that are not supported by the 
bootstrap compiler, but are supported by the newer compiler.


I don't know an "OPTFPC", and no files grep for it in the FPC or lazarus 
repos ?


I came across OPTNEW here https://wiki.freepascal.org/LLVM

But now I am trying to play with the rather old fpc build script for 
the laz installer.

And it calls

%MAKEEXE% compiler_cycle PP=%RELEASE_PPC% >> %LOGFILE% 2>&1
%MAKEEXE% rtl_clean  PP=%COMPILER% >> %LOGFILE%
%MAKEEXE% rtl packages  PP=%COMPILER% OPT="-Ur -CX" >> %LOGFILE%
%MAKEEXE% utils  PP=%COMPILER% OPT="-CX -XX -Xs" 
DATA2INC=%SOURCE_DIR%\utils\data2inc >>

...

And giving it just OPT= does not seem to do the trick.


Oh, yes of course, ideally rewrite that old script... Well "someday" 



 but I always use the toplevel makefile. I haven't tried to manually 
compile parts of the project for non debug purposes like that  since FPC 
1.0.x days..  Even the already old buildfaq doesn't document such 
partial compiling.



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

[fpc-devel] waitformultipleobjects

[Marco van de Voort via fpc-devel]

. from Linux  :dances:


from https://www.theregister.com/2023/09/27/osseu_steam_os_3/


Wherever possible, WINE converts Windows API calls to Linux ones, but 
sometimes, there is no matching Linux API. If there isn't, García said, 
/"Wine needs to implement the missing parts. This can result in 
overhead, and it's not always easily solvable in userspace. Solution: 
new Linux features to fill in the missing gaps."/


One recent example is the new |futex_waitv()| 
 call in kernel 5.16, 
which brings a new API to Linux that's like Win32's 
|WaitForMultipleObjects()| 
 
call, as this Collabora blog post 
 
explains in depth. Another patch 
 
brings /optional/ case-insensitivity  
to the F2FS, the Flash-friendly file system 
. As another example, 
Valve and its partners are also working on more reliable user-space 
spinlocks .


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

Re: [fpc-devel] fpc compiler wrong encoding in console output on Windows

[Marco van de Voort via fpc-devel]

On 30-8-2023 15:26, Ondrej Pokorny via fpc-devel wrote:


Yes, Tomas, in other words: maybe you enabled "Beta support for UTF-8" 
in language options on your Windows?



Try compiling the compiler with the .lpi and turn on the utf-8 option in 
the lazarus application/manifest screen.


But that makes it Windows 10  1905+ or so.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Using case statement instead of VTable

[Marco van de Voort via fpc-devel]

On 11-4-2023 12:11, Hairy Pixels via fpc-devel wrote:

Btw, I was curious because I haven’t done this in so many years but is this 
basically how a VTable looks in procedural code?


Every class has a reference to class type information stored at negative 
offsets. The class type info contains VMT, IVMT, the class name etc.  
The table is compile time (iow a structured constant in procedural 
pascal) and the layout of that table is roughly  described in objpash.inc:


 const
   vmtInstanceSize = 0;
   vmtParent   = sizeof(SizeInt)*2;
   { These were negative value's, but are now positive, else classes
 couldn't be used with shared linking which copies only all 
data from
 the .global directive and not the data before the directive 
(PFV) }

   vmtClassName    = vmtParent+sizeof(pointer);
   vmtDynamicTable = vmtParent+sizeof(pointer)*2;
   vmtMethodTable  = vmtParent+sizeof(pointer)*3;
   vmtFieldTable   = vmtParent+sizeof(pointer)*4;
   vmtTypeInfo = vmtParent+sizeof(pointer)*5;
   vmtInitTable    = vmtParent+sizeof(pointer)*6;
   vmtAutoTable    = vmtParent+sizeof(pointer)*7;
   vmtIntfTable    = vmtParent+sizeof(pointer)*8;
   vmtMsgStrPtr    = vmtParent+sizeof(pointer)*9;
   { methods }
   vmtMethodStart  = vmtParent+sizeof(pointer)*10;
   vmtDestroy  = vmtMethodStart;
   vmtNewInstance  = vmtMethodStart+sizeof(codepointer);
   vmtFreeInstance = vmtMethodStart+sizeof(codepointer)*2;
   vmtSafeCallException    = vmtMethodStart+sizeof(codepointer)*3;
   vmtDefaultHandler   = vmtMethodStart+sizeof(codepointer)*4;
   vmtAfterConstruction    = vmtMethodStart+sizeof(codepointer)*5;
   vmtBeforeDestruction    = vmtMethodStart+sizeof(codepointer)*6;
   vmtDefaultHandlerStr    = vmtMethodStart+sizeof(codepointer)*7;
   vmtDispatch = vmtMethodStart+sizeof(codepointer)*8;
   vmtDispatchStr  = vmtMethodStart+sizeof(codepointer)*9;
   vmtEquals   = vmtMethodStart+sizeof(codepointer)*10;
   vmtGetHashCode  = vmtMethodStart+sizeof(codepointer)*11;
   vmtToString = vmtMethodStart+sizeof(codepointer)*12;

The VMT has one pointer for each virtual method in a class. In e.g. 
TAnimal version of the table those pointers would point to the TAnimal 
copy of the virtual methods or a method that raises an "abstract" 
exception if the method is abstract.  The VMTs are linked (the TDog 
table points to TAnimal in its parent pointer, which in turn points to 
its parent) for the IS and AS functionality, but not for VMTs


The TDog version of the table they point to the TDog version.

So basically the tdog.create would only allocate memory, and initialize 
the first "field" with a pointer to the tdog class structured constants, 
and advance the pointer to the next field and return that as the 
instance pointer.


const ddogclassinfo : array [0..3]of pointer = 
(@parent,@vmtmethod1,@vmtmethod2,@vmtmethod3);


If the class (TDog) overrides the method, it points to the tdog 
reference, if not, this table still lists the TAnimal version of the method.



constructor TDog.Create;

begin

  result:=NewInstance; // allocate memory for the instance

  ppointer(result)^:=@dogclassinfo;

  inc(result,sizeof(pointer));

end;


Dispatch then becomes in simplified Pascal  (assume that "instance" is a 
initialized class)


var vmt : pointer;

vmt:=ppointer(instance)^;

tthemethod(ppointer(vmt)[n]).themethod(parameter);

... with n the number of the respective virtual method, and TTheMethod 
its signature.  Handling all those indexes, signatures and generating 
the parameter loading into registers, stack is the core work of the 
compiler.


Note that Delphi 1 had a different way of dispatch, called "dynamic" 
(the 16-bit compiler had to be much more careful with memory), at the 
expense of performance. IIRC that version kind of worked like your 
scheme, where every class only had a table for the methods it really 
had, leaving the rest up to a function in the parent. I don't recall the 
exact details (I suggest an old Delphi manual or mastering Delphi for 
that).  Free Pascal ignores this directive, and doesn't implement it.




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

Re: [fpc-devel] Using case statement instead of VTable

[Marco van de Voort via fpc-devel]

On 11-4-2023 10:41, Hairy Pixels via fpc-devel wrote:
  

  case animal.type of
TDog: TDog(animal).DoSomething;
TCat: TCat(animal).DoSomething;
TMouse: TMouse(animal).DoSomething;
  end;

This doesn't happen. There is no class that is TDog,Cat and mouse. Usually a 
VMT governs the relation between parent and child, i.e.   TDog and TAnimal.  
The TDog nor the TAnimal implementation has no knowledge of the other mammals.

Address this part first since maybe my example was poor. I was trying to model 
how polymorphism is done in pure procedural code. I used to write code like 
this so I kind of remember.

The idea is that there is a record with an enum which is the type of the 
object. Then anytime you have a polymorphic function (an override) you dispatch 
on it using a case.


That's what I thought, yes. But the whole analysis stays the same:

- you don't have a list of all possible polymorphic types in the 
application when you compile the average dispatch point, that is in the 
realm of whole-program optimization.   (I saw your later mail that you 
understood this, but I already composed this message when it arrived)


- The code is still more bulky. To get the type from the instance 
pointer is as expensive as the getting the vmt, and while the dispatch 
via the VMT is a single instruction on x86 (call *[vmt+offset]), you 
still have to spend a comparison and a branch per case (dog/cat/mouse) 
extra, with as only saving grace that the indirection of the call 
instruction disappears. Both bulkier and slower.


Another issue that I just thought about:

- you now only consider one virtual method per class. But think of more 
complex class hierarchies where various methods are introduced at 
various levels. Every virtual method then gets its own set of possible 
classes, and thus enum. This reduces to one entry per virtual method, 
just like in the VMT, only difference is that it is an enum instead of a 
pointer. (but the VMT pointer table is duplicated in the case statements 
of every dispatch call)


To judge new language schemes, always factor in multi unit examples, and 
ask yourself what you know at each point of the compilation. (e.g. 
typically you only know the interface of an USES'd unit, and not its 
implementation, and not other units). Similarly, the simple case is only 
a step up to also evaluate more elaborate cases. The devil is always in 
the details.




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

Re: [fpc-devel] Using case statement instead of VTable

[Marco van de Voort via fpc-devel]

On 11-4-2023 07:23, Hairy Pixels via fpc-devel wrote:

Strange question but I heard it brought up during a discussion and I was very 
curious what compiler people think about it.


I hope you don't mind me replying as non compiler person :-)



The question is, instead of using a virtual method table would it be feasible 
to use a case statement on the real class type and make a dispatch routine for 
each method call?

For example assume “type” is the internal type of the class (where a VTable 
would be) and a call to “animal.DoSomething()” is called which would internally 
basically be this dispatch table:

  case animal.type of
TDog: TDog(animal).DoSomething;
TCat: TCat(animal).DoSomething;
TMouse: TMouse(animal).DoSomething;
  end;


This doesn't happen. There is no class that is TDog,Cat and mouse. 
Usually a VMT governs the relation between parent and child, i.e.   TDog 
and TAnimal.  The TDog nor the TAnimal implementation has no knowledge 
of the other mammals.




The reason this was brought up was because virtual methods can’t be inlined and 
this would allow that but I think there would be more overhead overall to have 
all these case statements on every virtual method call.


Much more, keep in mind your example above doesn't even have parameters.

Keep in mind that the virtual call is fairly cheap to begin with, you 
load the VMT from the instance references (first field), and then the 
method pointer at an fixed offset relative to that. Two instructions on 
x86 with its many addressing modes, only slightly more on non-x86, I 
would guess, and no branches.


Your solution would also need to load some reference to the class type, 
(the first instruction) and then a compare and branch for each case.


But the core problem is that you don't have an overview of all other 
descendants in the compiler. Those can be fragmented over multiple 
units, and then you touch the problem that whole program optimization 
like de-virtualization tries to solve.


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

Re: [fpc-devel] Question on constref

[Marco van de Voort via fpc-devel]

On 2-2-2023 12:00, Ondrej Pokorny via fpc-devel wrote:



The only disadvantage is that you get a FreeAndNil copy for every type 
you pass into the parameter (?)


Are they actually made global ? Will two freeandnil in 
different units use the same?


But that is just curiousity, IMHO this remedy is worse than problem. 
Obviously even.



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

Re: [fpc-devel] Unicode RTL for FPC

[Marco van de Voort via fpc-devel]

On 6-1-2023 20:36, Adriaan van Os via fpc-devel wrote:

Michael Van Canneyt via fpc-devel wrote:


- String = UnicodeString, Char=WideChar


UnicodeString ? ? I don't know what that is supposed to be.


It is named after Microsofts use of the word unicode. Which was 
originally UCS2,  but morphed into UTF16 in later versions.


The reason however is Embarcadero's adaptation of it in Delphi.

For the encoding advocacy, these discussions were already held in 
2009-2010. Let's not have them again.


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

Re: [fpc-devel] Sorting tests

[Marco van de Voort via fpc-devel]

On 29-11-2022 17:34, J. Gareth Moreton via fpc-devel wrote:
This is why I hope my own improvement to the version in TArrayHelper 
could be used instead:


https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/334

Now that I know where Introsort is in the sortalgs.pp unit, I'll see 
about improving Introsort there too.


Regarding a stable sort, what does GCC's "std::stable_sort" use? 
https://www.youtube.com/watch?v=kPRA0W1kECg=3m5s - it resembles 
merge sort.  (The algorithm before it in the video, "std::sort", is 
introsort, but it postpones doing the insertion sort until the very 
end, which doesn't work in practice because of caching issues)


Usually it is heapsort that is picked as alternative to quicksort if 
stable algo is needed.


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

Re: [fpc-devel] Just need to double check the size of Integer

[Marco van de Voort via fpc-devel]

On 24-11-2022 14:59, Michael Van Canneyt via fpc-devel wrote:


SizeInt = SmallInt;

(IMHO get rid of small and short in general, and simply put int8/16 
instead. But that might require compiler work?)

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

Re: [fpc-devel] Just need to double check the size of Integer

[Marco van de Voort via fpc-devel]

On 24-11-2022 14:25, Ondrej Pokorny via fpc-devel wrote:

Am 24.11.2022 um 14:15 schrieb Marco van de Voort via fpc-devel:

On 24-11-2022 14:13, J. Gareth Moreton via fpc-devel wrote:


I just need to double-check something.  Under CPU16, SizeInt and 
SizeUInt are declared as follows:


  SizeInt = Integer;
  SizeUInt = Word;

Is Integer 16-bit in this case? 


Yes.


Are you sure? systemh.inc is compiled with {$mode objfpc} (see line 
22), so Integer within the system unit is 32-bit.


1. Then why does the posted code print 2?

2. using {$mode objfpc in the system unit can't load objpas that 
overrides the integer, even if the mode is set.




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

Re: [fpc-devel] Just need to double check the size of Integer

[Marco van de Voort via fpc-devel]

On 24-11-2022 14:13, J. Gareth Moreton via fpc-devel wrote:


I just need to double-check something.  Under CPU16, SizeInt and 
SizeUInt are declared as follows:


  SizeInt = Integer;
  SizeUInt = Word;

Is Integer 16-bit in this case? 


Yes.

I always thought Integer was defined as a signed 32-bit integer under 
FreePascal. 


No. Only in objfpc/delphi modes, and system is in $mode FPC. Unit objpas 
overrides this definition and is loaded in objfpc/delphi mode.





begin
writeln(sizeof(integer));
end.

without any $mode (so $mode fpc) will write 2, even on 64-bit systems.



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

Re: [fpc-devel] An interesting thought... AI

[Marco van de Voort via fpc-devel]

On 11-11-2022 09:57, Jonas Maebe via fpc-devel wrote:

On 11/11/2022 00:44, J. Gareth Moreton via fpc-devel wrote:
My slight concern is that the x86 peephole optimizer is becoming 
pretty bloated now


An alternative could be to specify the peephole optimizations in a 
pattern matching format, and then either write a tool that converts 
them to a bunch of if-then-else statements, or interpret this format 
directly in the compiler.



Or maybe predicting branch taken  taking more into consideration than 
which node of if..then..else it is.




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

[fpc-devel] textmode IDE and newer GDB

[Marco van de Voort via fpc-devel]

Fyi

I wanted to test a textmode IDE bugreport with trunk (on win32) 
recently, and it wouldn't start even after wiping configuration. It just 
dumped two lines with version info and then hung itself.


Turned out it was the gdb executabe, which was one of the Lazarus 
"alternate" ones, v8.2. If this version is not suitable, maybe there can 
be some error message/terminate in such cases?



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

Re: [fpc-devel] C library header - var vs pointer for function arguments

[Marco van de Voort via fpc-devel]

On 4-8-2022 07:40, Michael Van Canneyt via fpc-devel wrote:



It's best to use pointers, but you can always provide overloads with var
arguments.

IIRC it is best to not do this automatically for functions with two such 
cases (two by ref, so var or pointer parameters).


This because small programming mistakes then often trigger "can't 
determine which overloaded function to call", which is often confusing 
for people.


In the Windows headers (rtl/win/wininc and winunits*) I therefore only 
overload with VAR when it is needed for some compatibility reasons 
(either FPC self compatibility or Delphi)


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

[fpc-devel] freebsd alive again

[Marco van de Voort via fpc-devel]

Fyi,

Last weekend I got FreeBSD working again, integrating a patch from the 
ports maintainer.


Both fixes and trunk should work again, but

- ld.bfd must be installed.

- for bootstrapping, ld must also be symlinked to ld.bfd, at least till 
a new release is done.



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

Re: [fpc-devel] get and putin $modeswitch isooi

[Marco van de Voort via fpc-devel]

On 20-6-2022 22:10, Sven Barth via fpc-devel wrote:
Put and Get are not part of modeswitch ISOIO, because they're not 
intrinsics and are instead provided by the ISO7185 unit which is only 
used for modeswitch ISO. As that unit also contains functionality 
that's not covered by the ISOIO modeswitch (some types, Round 
functions) it's not used for that modeswitch, but only together with 
the mode. 


I relayed your answer.

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

Re: [fpc-devel] ConvUtils: question regarding Delphi compatibility. How to proceed?

[Marco van de Voort via fpc-devel]

On 19-6-2022 12:09, Bart via fpc-devel wrote:

It feels a bit counter-intuïtive to me though.
IMO it should simply not be allowed to call RegisterConversionType()
with either of the TConversionProc parameters being nil, since that
makes no sense to me, and it will inevitably lead to exceptions later
on in the code.


Agreed.  This is not really a much used unit where extreme bug 
compatibility pays off. Better keep it straightforward.



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

Re: [fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums

[Marco van de Voort via fpc-devel]

On 8-6-2022 15:14, Bart via fpc-devel wrote:

Changing our TConvType to word will potentially break existing programs though.


I doubt that there are mission critical convutils programs out there, 
given the fact that it took 10+ years  to find out the temperature 
conversion didn't work :-)


Usage is low, risk is small, I say, go ahead.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] get and putin $modeswitch isooi

[Marco van de Voort via fpc-devel]

There was a question about $modeswitch ISOIO  on stack overflow, and 
specially why get() and put() are not part of it.


The documentation about this switch seems very sparse. As far as I can 
see it is mostly the lookahead and switching reset and read/write 
handlers to their ISO variants.


Does anybody know? Or is it simply because get/put support is newer?

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

Re: [fpc-devel] Unable to find resource

[Marco van de Voort via fpc-devel]

On 22-4-2022 09:12, Marc Weustink via fpc-devel wrote:


On a project I'm working on I needed to refactor some units. After I 
finished, I got a linking error about a duplicate resource. Maybe 
accidentally a stale one got linked, so I removed 2 occurrences.

And now the compiler complains it cannot find the resource.



Debug: parsing parameter '.\lib\x86_64-win64\x_service.res'
Debug: parsing parameter 'C:\Users\marc\x\x_service.res'


Well that is duplicate obviously.

Maybe you did some manual cmdline build that left a .res in the working 
dir , and your project has a stale {$R *.res} in the .dpr ?

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

Re: [fpc-devel] Package build failure under i386-win32

[Marco van de Voort via fpc-devel]

On 3-4-2022 15:44, J. Gareth Moreton via fpc-devel wrote:

Hi everyone,

It seems at some point, something was introduced to the compiler that 
causes a package to fail to build (specifically 
packages\chm\src\chmwriter.pas) with an assembler-level range check 
error.  If you run "make all" under i386-win32 with "-CriotR -a" 
options, the error is triggered.  It only occurs under -CriotR and, 
notably, it does NOT occur when -a is omitted.




Note that that file changed last week:
*54c95288f868a762f1caa9d8e62fa6f193237cf2 
* 
marcoonthegit Sat Mar 26 15:00:15 2022

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

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

[Marco van de Voort via fpc-devel]

On 14-1-2022 16:33, Ben Grasset via fpc-devel wrote:
On Fri, Jan 14, 2022 at 1:27 AM Sven Barth via fpc-devel 
 wrote:


(though to be fair it does the same on 32-bit as well)


Yeah, MSVC (for some reason) universally defines "long double" as 
exactly an alias for regular 64-bit double, whereas GCC and Clang 
(more correctly IMO) define it as an 80-bit type equivalent to FPC's 
traditional "extended". So even on 32-bit with MSVC you have to 
hand-write assembly to make use of x87 FPU instructions.


Did you test a windows gcc (win64 SEH) or a SJLJ "posix" (basically 
unported Unix)  gcc ?


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

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

[Marco van de Voort via fpc-devel]

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 I don't get why it would be 
fine for Linux to have a zillion archives for different configurations 
here: https://sourceforge.net/projects/freepascal/files/Linux/3.2.2/



As said, Windows 64-bit is a special case because it doesn't 
support/recommend extended. This makes cross compiling to targets that 
do difficult till we have softfloat support.


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

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

[Marco van de Voort via fpc-devel]

On 4-1-2022 17:15, J. Gareth Moreton via fpc-devel wrote:

I neglected to include -Cpcoreavx, that was my bad.  I'll try again.

According to Intel® 64 and IA-32 Architectures Software Developer’s 
Manual, Vol 2B, Page 4-391.  The zero flag is set if the source is 
zero, and cleared otherwise.  Regarding an undefined result, I got 
confused with the BSF and BSR commands, sorry.  I guess I was more 
tired than I thought!  POPCNT returns zero for a zero input.


Ok, that's what I thought.

I played a bit by adding code alignments to loops in the SSE code, but 
it only seems to slow the core loop rather than accelerate it (align 
before the branch location and/or branch target)


Did you have any thoughts about moving up the NOT instruction ?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

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

[Marco van de Voort via fpc-devel]

On 4-1-2022 16:31, Martin Frb 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.


I looked up popcnt and found nothing about not setting if zero. (E.g. 
https://www.felixcloutier.com/x86/popcnt )


I meanwhile also ran on my Ryzen 4800H laptop and updated the version on 
the web with the stats. The stats for the  long string are about as fast 
as on my i7-3770 (laptop vs desktop memory bandwidth? The ryzen should 
be faster in any way?!?), but the short one (40 bytes) is significantly 
faster. What I don't get is why the assembler version seems 
systematically faster even for the short code. The generated asm is 
nearly the same.


Also notable is that on this machine with popcnt (-Cpcoreavx), the 
popcnt version is as fast as the add function within error margins, so 
probably popcnt instruction is faster(lower latency) and thus less of a 
bottleneck on this machine.  Note that the POP() function is half the 
size, so that makes it better for newer machines.


-

Note that I test on Windows, so it might be that the "two times load" is 
a difference somehow due to different codegeneration on windows





About UTF8LengthFast()

Well, before I get to this, I noted something weird.

2 runs, compiled with the same compiler ( 3.2.3 ), and the same 
settings, with the only difference: -gw3 or not -gw3
=> And the speed differed.  600 (with dwarf)  vs 700 (no dwarf) / 
reproducible.


I also have seen this, while working on the code. And indeed mainly with 
the "fast" one. It also explains why the assembler is always consistent, 
it suffers less from detail code changes when I e.g. update FPC from 
git, and thus different alignment. (assuming that the section starts are 
always aligned)



Alignment. 16 vs 32 bit. Can that make a difference?
According to: 
https://stackoverflow.com/questions/61016077/32-byte-aligned-routine-does-not-fit-the-uops-cache


Seems to be a problem of the Skylake and later archs, which I no longer 
have. The i7 is too old, and the others are AMD.



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

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

[Marco van de Voort via fpc-devel]

On 4-1-2022 01:06, J. Gareth Moreton via fpc-devel wrote:

Prepare for a lot of technical rambling!

This is just an analysis of the compilation of utf8lentest.lpr, not 
any of the System units.  Notably, POPCNT isn't called directly, but 
instead goes through the System unit via "call fpc_popcnt_qword" on 
both 3.2.x and 3.3.1.  A future study of "fpc_popcnt_qword" might 
yield some interesting information.


Did you pass -Cpcoreavx    ?

# [381] Result += PopCnt(qword(nx));
    popcntq    %r10,%r8
    addq    %r8,%rbx



In this situation, one can replace %r11 with %r13 in the 3rd and 4th 
instructions so the massive constant isn't assigned twice:


The large constant(s) should be hoisted out of the loop. This is done in 
the assembler code:


.Lj11:
    movq    (%rcx),%r8
    movq    %r8,%r10
    andq    %rdx,%r10
    notq    %r8
    shrq    $7,%r10
    shrq    $6,%r8
    andq    %r8,%r10
    subq    %r8,%rax   // subtract from rax=length(s). Iow 
algorithm is slightly different. don't sum


    // correction but 
directly subtract from length. Saves bytecount from being a live value 
till the end


 popcntq    %r10,%r8
    addq    $8,%rcx
    decq    %r11
    jne    .Lj11

As far as I can see the assembler version is about 25-33% faster for low 
counts (40 bytes) . For larger strings, the SSE2 code kicks in and that 
is a solid factor 2.  (270 vs 538 for the fastest "add", see table in 
the comments of the source)


Note that I use pop/fast because they are simpler and I only use for low 
counts. The SSE2 version is more like the ADD variant.


For actual reduction of pipeline stalls, I'm not quite sure how smart 
the Intel CPU firmware is and if rearranging instructions would 
actually improve throughput or not.  For example, on 3.2.x, there are 
these four instructions that configure parameters and preserve %rax:


I tried for above code on godbolt, attached is the analysis. (both for 
the asm loop, the popcnt loop from my code and the popcnt with the 
movabs removed to test hoisting)


Note my 3.3.1 (from 29 dec) doesn't seem to generate two loads. With my 
limited assembler abilities I'd say it is not the hoisting that makes 
the manual asm loop faster as I first thought, but moving the NOT up to 
where it is.


Also, POPCNT is handled in the System unit and is not inlined, mainly 
because of how an input of zero is handled (the function has to return 
255 in the result, whereas Intel's POPCNT instruction sets the zero 
flag and leaves the result undefined).


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?


manual asm :
--

.Lj47:
add rsi,1
mov r8,qword [rcx]
mov r10,r8
mov rdi,-9187201950435737472
and r10,rdi
shr r10,7
not r8
shr r8,6
and r10,r8
mov r11,r10
popcnt  r8,r10
add rbx,r8
add rcx,8
cmp rsi,r9
jnge.Lj47

llvm-mca: -mcpu=ivybridge

Iterations:100
Instructions:  1200
Total Cycles:  378
Total uOps:1200

Dispatch Width:4
uOps Per Cycle:3.17
IPC:   3.17
Block RThroughput: 3.0

Instruction Info:
[1]: #uOps
[2]: Latency
[3]: RThroughput
[4]: MayLoad
[5]: MayStore
[6]: HasSideEffects (U)

[1][2][3][4][5][6]Instructions:
 1  5 0.50*   mov   r8, qword ptr [rcx]
 1  1 0.33mov   r10, r8
 1  1 0.33and   r10, rdx
 1  1 0.33not   r8
 1  1 0.50shr   r10, 7
 1  1 0.50shr   r8, 6
 1  1 0.33and   r10, r8
 1  1 0.33sub   rax, r8
 1  3 1.00popcntr8, r10
 1  1 0.33add   rcx, 8
 1  1 0.33dec   r11
 1  1 1.00jne   .Lrestqwords

Resources:
[0]   - SBDivider
[1]   - SBFPDivider
[2]   - SBPort0
[3]   - SBPort1
[4]   - SBPort4
[5]   - SBPort5
[6.0] - SBPort23
[6.1] - SBPort23

Resource pressure per iteration:
[0][1][2][3][4][5][6.0]  [6.1]  
 -  - 3.66   3.67- 3.67   0.50   0.50   

Resource pressure by instruction:
[0][1][2][3][4][5][6.0]  [6.1]  Instructions:
 -  -  -  -  -  - 0.50   0.50   mov r8, qword ptr 
[rcx]
 -  - 0.21   0.63- 0.16-  - mov r10, r8
 -  - 0.35   0.61- 0.04-  - and r10, rdx
 -  - 

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

[Marco van de Voort via fpc-devel]

On 3-1-2022 12:54, Martin Frb via fpc-devel wrote:



fpc 3.2.3 /   fpc 3.3.1

fst 594   fst 688
fst 578   fst 703
fst 578   fst 687
fst 562   fst 688




Fyi, the latest asm version (+fst/pop/add/naieve) is at

http://www.stack.nl/~marcov/utf8lentest.lpr

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

Re: [fpc-devel] FPC trunk building lazarus trunk fails with compiler AV ?

[Marco van de Voort via fpc-devel]

On 12-12-2021 17:21, Yuriy Sydorov via fpc-devel wrote:

On 12.12.2021 16:24, Marco van de Voort via fpc-devel wrote:


On 12-12-2021 15:19, Florian Klämpfl via fpc-devel wrote:


What -Cp/-Cf option do you use?


To compile FPC:

set CPUOPTS=-O2  -Opcoreavx -Cpcoreavx
set CPUOPTS64=-Cfavx

I didn't enter those in Lazarus I think, so that should be pretty 
much default.


Should be fixed now. The AVs have occurred only when targeting the AVX 
FPU.


Ok, got another error, but that turned out to be the result of unit 
baseenc changing packages somewhere in the last few weeks.


After fixing that, everything works again (without changing any of the 
scripts), so THANKS!


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

Re: [fpc-devel] FPC trunk building lazarus trunk fails with compiler AV ?

[Marco van de Voort via fpc-devel]

On 12-12-2021 15:19, Florian Klämpfl via fpc-devel wrote:


What -Cp/-Cf option do you use?


To compile FPC:

set CPUOPTS=-O2  -Opcoreavx -Cpcoreavx
set CPUOPTS64=-Cfavx

I didn't enter those in Lazarus I think, so that should be pretty much 
default.

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

Re: [fpc-devel] FPC trunk building lazarus trunk fails with compiler AV ?

[Marco van de Voort via fpc-devel]

On 12-12-2021 14:47, Yuriy Sydorov via fpc-devel wrote:



Any pointers?


I've tried to reproduce the AV while building Lazarus on i386-win32 
with -O2 and -O3 options, but it works for me.

What compiler options have you used to build Lazarus?



lazbuild --pcp=c:\repo\lazarusgit\config --build-ide=


I'll send my FPC buildscript and lazarus config dir in private.


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

[fpc-devel] FPC trunk building lazarus trunk fails with compiler AV ?

[Marco van de Voort via fpc-devel]

FPC trunk building lazarus trunk fails with compiler AV ?

An old ghost seems to have resurfaced. I didn't build a development 
lazarus for a while (I used a stable one for work), but at least 1-2 
weeks I have this problem:



(3104) Compiling postscriptcanvas.pas
(3104) Compiling printers.pas
(3104) Compiling postscriptunicode.pas
c:\repo\lazarusgit\lcl\postscriptcanvas.pas(707,3) Warning: (6060) Case 
statement does not handle all possible cases
c:\repo\lazarusgit\lcl\postscriptcanvas.pas(722,30) Error: (1026) 
Compilation raised exception internally

Fatal: (1018) Compilation aborted
An unhandled exception occurred at $00499477:
EAccessViolation: Access violation
  $00499477  GET_ALIAS,  line 1214 of rgobj.pas
  $0049C655  INSTR_SPILL_REGISTER,  line 2834 of rgobj.pas
  $0049BDE3  SPILL_REGISTERS,  line 2572 of rgobj.pas
  $004987DF  DO_REGISTER_ALLOCATION,  line 659 of rgobj.pas
  $0048935A  DO_REGISTER_ALLOCATION,  line 903 of cgobj.pas
  $004E2659  GENERATE_CODE_TREE,  line 1616 of psub.pas
  $004E450B  READ_PROC,  line 2840 of psub.pas
  $004E49F9  READ_DECLARATIONS,  line 3072 of psub.pas
  $0043D00A  COMPILE,  line 402 of parser.pas
  $004D44AE  LOADPPU,  line 2276 of fppu.pas
  $005AF153  LOADUNITS,  line 523 of pmodules.pas
  $005AFFA8  PROC_UNIT,  line 983 of pmodules.pas
  $0043D00A  COMPILE,  line 402 of parser.pas
  $00418526  COMPILE,  line 288 of compiler.pas

Compiler AVs in postscript* units have happened before afaik.

Any pointers?

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

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

[Marco van de Voort via fpc-devel]

Op 25-10-2021 om 13:06 schreef LacaK via fpc-devel:
The base output  is starting to work somewhat. 
http://www.stack.nl/~marcov/mergelogs32/restset.html
Marco, can I see what commits were already merged ? (and what not - 
iow what is candidate for merging)


I don't really maintain lists of what was merged, only what was 
candidate for merge(*)


Basically, it just finds all eligible revs using the "merging" repo 
script, and then sorts that over categories, with a "rest" category for 
not yet categorized revs, and a "all" category for all revs. Which revs 
are in which categories is maintained by a simple ini file.


All category files are in html (more dense easier to read) and in .txt 
(easier to grep) format.


The main index lists all categories: 
http://www.stack.nl/~marcov/mergelogs32/


with the "rest" set being the last one. You are most probably interested 
in the "Database" subcategory:


http://www.stack.nl/~marcov/mergelogs32/fcl-db.html

http://www.stack.nl/~marcov/mergelogs32/fcl-db.txt

These are _NOT_ yet complete, some fixes to database headers are not in 
them yet. I still have a lot of the revisions from july till now to 
categorize.


but beware,  such files consists out two parts. Revisions that are 
eligible (first part), and revisions that were eligible and categorized, 
but have been merged meanwhile (second part after "(inactive) Revisions 
in this set" header).


I can do three levels of grep on this. Only on the "rest" set, which is 
the common mode, to see which new files in some category (e.g. "fcl-db/" 
) there are.


To resolve conflicts I can also search on all eligible revisions with 
the option to exclude some revision sets that contain very large files 
(very large branches merged in, and makefile regen end up there, because 
they touch many files and often grep while being non relevant.


(*) In theory, you could find out by checking what is eligible of the 
last release branch, and subtracting the eligible of the fixes branch 
from it, but I don't know yet how to do that in git.  It is also not 
perfect, there will be some pollution with e.g. version update commits.


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

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

[Marco van de Voort via fpc-devel]

Op 24-10-2021 om 18:13 schreef Marco van de Voort via fpc-devel:


When you have a hash, you can translate it in a "relative" revision 
number by:


git describe  | sed -nr 's/.*-(.*)-.*/\1/p'

It is basically the number of commits after the last annotation tag 
(3.3.1 in case of main).


I have the date field in the revisions, so that is not so much of a 
problem. But due to historic reasons, the program does set logic with 
stringlists of only SVN revs, and only fetches logs and other meta 
data later. So just the order of things has to change completely.


Not fundamental, just a lot of rearranging.

The base output  is starting to work somewhat. 
http://www.stack.nl/~marcov/mergelogs32/restset.html


In some output there is still a 'r' before revs, and the header parts 
(rev/date/author) are not yet nicely folded yet, making the HTML output 
less concise, but that is only makeup, I'll clean this up bit by bit.


More important is getting the actual set logic (show all uncategorized 
commits matching "fcl-pascal/" ) working again.


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

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

[Marco van de Voort via fpc-devel]

Op 24-10-2021 om 17:52 schreef Florian Klämpfl via fpc-devel:


This week I've been working on getting the merge logs etc working 
again. Things are showing info again, but sorting is broken (since 
you can't simply sort the revs anymore).


When you have a hash, you can translate it in a "relative" revision 
number by:


git describe  | sed -nr 's/.*-(.*)-.*/\1/p'

It is basically the number of commits after the last annotation tag 
(3.3.1 in case of main).


I have the date field in the revisions, so that is not so much of a 
problem. But due to historic reasons, the program does set logic with 
stringlists of only SVN revs, and only fetches logs and other meta data 
later. So just the order of things has to change completely.


Not fundamental, just a lot of rearranging.


Thx for the merges

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

Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions

[Marco van de Voort via fpc-devel]

Op 24-10-2021 om 14:09 schreef Florian Klämpfl via fpc-devel:



Am 10.10.2021 um 15:55 schrieb Florian Klämpfl via fpc-devel 
:

Reminder :)

So far I have only the second avr merge list from Christo open. Anything else?

Next reminder, meanwhile, I merged the avr stuff.


This week I've been working on getting the merge logs etc working again. 
Things are showing info again, but sorting is broken (since you can't 
simply sort the revs anymore).


Anyway, I grepped on my name, and found these:

622554b59fe19bf0ff1dcf18c1106db960305ef6
84507b49c217cf6cd37023a79c1cff075bb3cb03

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

Re: [fpc-devel] Building a debug version of FPC-main on Windows

[Marco van de Voort via fpc-devel]

Op 8/28/2021 om 10:52 PM schreef Werner Pamler via fpc-devel:

Am 25.08.2021 um 20:53 schrieb Marco van de Voort via fpc-devel:
Sorry. I'm on holiday, and I only check in occasionally at night. Try 
changing PP= to FPC=
Thank you, Marco. Now I did already the second successful build of a 
older clone after an update. This really was the solution. But what is 
the difference between PP= and FPC= ?


As michael says, the make file use both FPC and PP which point 
internally to the corresponding binaries (fpc(.exe) and ppc(.exe)).


What I think is that the FPC binary found in the path  was queried (and 
found a ppc binary in the same dir) and overrode your PP= setting.


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

Re: [fpc-devel] Building a debug version of FPC-main on Windows

[Marco van de Voort via fpc-devel]

Op 8/24/2021 om 4:22 PM schreef Werner Pamler via fpc-devel:

Am 23.08.2021 um 18:14 schrieb Marco van de Voort via fpc-devel:
[...] I notice is that you point lazarus to the ppu's in the FPC 
source tree [...]
Sorry, I don't understand: There is no Lazarus involved in my build 
script. If there is, show me the line and how you would modify it.


Sorry. I'm on holiday, and I only check in occasionally at night. Try 
changing PP= to FPC=

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

Re: [fpc-devel] Building a debug version of FPC-main on Windows

[Marco van de Voort via fpc-devel]

Op 8/23/2021 om 4:20 PM schreef Werner Pamler via fpc-devel:

Am 23.08.2021 um 14:06 schrieb Marco van de Voort via fpc-devel:

Op 8/23/2021 om 1:36 PM schreef Werner Pamler via fpc-devel:
make install all OPT=%OPTIONS% INSTALL_PREFIX=%FPC_DEST_DIR% 
PP=%BOOTSTRAP_COMPILER%
Shouldn't this (install all) be the other way around? Classically one 
builds it before one installs it.


It does not make a difference. Now I found out that when I delete the 
units directory manually before calling the batch, everything works 
correctly, even with the OPT parameter. I thought that the "clean" 
does this?


I looked again, and the only thing atypical that I notice is that you 
point lazarus to the ppu's in the FPC source tree, while maybe via 
fpc.cfg also the installed tree is included. Though  I don't understand 
why that would cause problems.

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

Re: [fpc-devel] Untranslatable (hardcoded) messages

[Marco van de Voort via fpc-devel]

Op 8/23/2021 om 3:11 PM schreef Bart via fpc-devel:

dows trickery - feel free to complain at Microsoft. ;-)
OK, just for my understanding of this:
I cannot see the file there (system32)
FPC looks for it there
Windows just says it's there (and silently redirects to syswow64 folder)
FPC looks at file, sees it's wrong, tells me the file in system32 is wrong.

Does that imply that, when I have a 32-bit program do a FindFirst for
common.dll in the system32 folder, Windows just tells the program that
the file is there?
For compilers this is always more difficult, since the mapping must 
match the target system rather than the host binary.

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

Re: [fpc-devel] Building a debug version of FPC-main on Windows

[Marco van de Voort via fpc-devel]

Op 8/23/2021 om 1:36 PM schreef Werner Pamler via fpc-devel:


make install all OPT=%OPTIONS% INSTALL_PREFIX=%FPC_DEST_DIR% 
PP=%BOOTSTRAP_COMPILER%


Shouldn't this (install all) be the other way around? Classically one 
builds it before one installs it.


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

[fpc-devel] chm docs 3.2.2 regenerated.

[Marco van de Voort via fpc-devel]

l.s.

It turned out that FPC 3.2.2's latex CHMs (ref/user/prog) missed TOC, 
and in Ref.chm's case index. This might trip up some IDE search 
algorithms, and direct access using CHM viewers.


The problem was due to one of the encoding related changes, which now 
has been worked around.


The new docs are on ftp as /fpc/dist/3.2.2/docs/doc-chm.zip

The original archive has been renamed doc-chmorg.zip


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

Re: [fpc-devel] Anyone an idea were/how to look for the missing merge in 3.0.2

[Marco van de Voort via fpc-devel]

Op 2021-07-01 om 01:35 schreef J. Gareth Moreton via fpc-devel:

Actually, remind me... what revision number is 3.2.0 based off?


r39628  mid august 2018


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

Re: [fpc-devel] Attn. Marco: typo in r49563

[Marco van de Voort via fpc-devel]

Op 2021-06-26 om 21:21 schreef Bart via fpc-devel:


You made a typo in the comment:
// extended colosr (from lazarus Graphics)
Should be
// extended colors (from lazarus Graphics)



Done


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

Re: [fpc-devel] mantis 0038496 custom variants and documentation

[Marco van de Voort via fpc-devel]

Op 2021-05-30 om 13:02 schreef Sven Barth via fpc-devel:




I think it is allowed to change the result type of the variant passed 
in binaryop(), but am not 100% sure, and also not sure if there are 
other things to keep an eye for (e.g. finalization of the existing 
value).


Does anybody know open source custom variant examples other than 
fmtbcd ?


The only one I'm aware of that makes use of BinaryOp is Python4Delphi 
( 
https://github.com/pyscripter/python4delphi/blob/master/Source/VarPyth.pas 
). mORMot derives its TSynInvokeableVariantType and thus its 
TDocVariant from TInvokableVariantType, but does not override the 
operator methods.


I think I saw this one before in March. I also remember the conclusion: 
this should be fixed in LefPromotion(), but FPC doesn't implement 
calling that method :-)

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

[fpc-devel] mantis 0038496 custom variants and documentation

[Marco van de Voort via fpc-devel]

Before the 3.2.2 release I looked into mantis 0038496 and now I come 
back to it.


I noticed that custom variants are completely undocumented, is this know 
(IOW should I file a bug?). What I wanted to look up are the rules for 
implementing binaryop, since that is where the problem is.


The bug is for the following code:

{$ifdef fpc}
 {$mode delphi}
{$else}
 {$apptype console}
{$endif}

uses variants,fmtbcd;
var
  fBCD1: TBcd;
  V1, V2, V3:Variant;
  L1: Integer;
begin
  L1:=123;
  fBCD1:=1234.345;

  V1:=123;
  V2:=VarFmtBCDCreate(fBCD1);
  V3:=V1 + V2;
  writeln(v3);
  readln;
end.

The addition finally ends up in  TFMTBcdFactory.BinaryOp which is 
declared as follows


procedure TFMTBcdFactory.BinaryOp(var Left: TVarData; const Right: 
TVarData; const Operation: TVarOp);


i.e.  not a 3 operand action, but a two operand.  This probably means 
that in the case of v3:=v1+v2 this is encoded as v1:=v1,v2,add, 
modifying V1.


The fmtbcd binaryop code however says that the left type (integer)  is 
not either double or a a FMTBCD custom variant and thus throws an exception.


I think it is allowed to change the result type of the variant passed in 
binaryop(), but am not 100% sure, and also not sure if there are other 
things to keep an eye for (e.g. finalization of the existing value).


Does anybody know open source custom variant examples other than fmtbcd ?






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

[fpc-devel] FPC 3.2.2 released

[Marco van de Voort via fpc-devel]

Hello,

Finally, the Free Pascal 3.2.2 release is available from our servers and 
from sourceforge.


Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

For an overview of what is new see the summary below

The website has been updated for the major targets and work is still 
being done for the rest.


All downloads are available at the main FTP server and sourceforge.

https://sourceforge.net/projects/freepascal/files/

ftp://ftp.freepascal.org/pub/fpc/dist/3.2.2/

Enjoy!

The Free Pascal Compiler Team



    Free Pascal Compiler

    Version 3.2.2

**

Free Pascal 3.2.2 is a minor release of the 3.2.x fixes branch. As such, it
contains mostly fixes of bugs discovered in the previous version, plus some
updates for included packages. In this case a new target was also backported
from trunk.

Please also see https://wiki.freepascal.org/User_Changes_3.2.2 for a list
of changes that may affect the behaviour of previously working code, and
how to cope with these changes.

The main highlights of this version:

Platforms:
  * New platform: aarch64-darwin
  * A new 32/64-bit combined installer for Windows.

Utilities:
  * fpcres provides support for compiling resources from *.rc files

Packages:
  * fcl-db extended with support for MySQL 8.0
  * fcl-passrc updates
  * pas2js updates
  * fpdoc updates
  * fcl-base includes new support for logging to StdOut and StdErr
  * rtl-extra includes improvements for Sockets

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

Re: [fpc-devel] Defer keyword

[Marco van de Voort via fpc-devel]

Op 2021-05-06 om 17:38 schreef Ryan Joseph via fpc-devel:

Something which annoys me about Pascal is cleanup in which a function exits in multiple 
places but there is no formal way to free memory which may be used in the current scope. 
I say ultimately Pascal needs some opt-in automatic reference counting for TObject but 
the "defer" keyword would be helpful alternative to what we have now, which is 
nothing.

The concept is very easy to understand and should be easy to implement by simply making a 
"defer" statement node which is added to a list and then called during function 
finalization like the other ref counted objects (dynamic array, interfaces etc).


But those types have refcounting built-in and always active. Things like 
defer don't, which makes that all objects gets refcounting overhead in 
case somebody needs it for "defer".


Contrary to Pascal both the language you reference have garbage 
collectors, so their objects are already managed anyway,




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

Re: [fpc-devel] FreeBSD PowerPC64 Port

[Marco van de Voort via fpc-devel]

Op 2021-04-18 om 11:40 schreef Florian Klämpfl via fpc-devel:

Am 18.04.2021 um 00:45 schrieb Curtis Hamilton via fpc-devel 
:

Is there any interest in porting FPC to Freebsd/PowerPC64?

I'm looking for some help with port FPC to FreeBSD on PowerPC.  Any assistance 
would be appreciated.


Interest in FreeBSD is apparently very little in the last years within the FPC 
universe, considering the half backend support even for x86-64.


Half backend support? Did you mean _LLVM_ backend support? There is 
none, save some work I did in Berlin.



Even more after the main FPC FreeBSD  port contributor Marco switched years ago 
to windows.


No, it was my remote shell account changing from FreeBSD on own hosted 
systems to a linux account on a commercial shared server. I mostly 
booted own systems under Windows since I left college (which, 
admittedly, in my case was fairly late)


But the real kicker was the LLVM migration that necessitates things in 
startup that I'm not capable off. Even less so with toolchains that 
randomly seem to drop sections instead of reporting an error.


I'm told that with FreeBSD13, the last lifeline, ld.bfd will be gone, 
and the last somewhat workable version(11) goes out of support in September.


If somebody can provide a base system (iow simple binaries and simple 
libc linked binaries) working on LLVM basis,  it should be easy to pick 
it up again though. Even with the old port, people often helped me with 
the startup code (Pierre with 64-bit, Florian and Jonas with 32-bit PIC 
iirc)



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

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

[Marco van de Voort via fpc-devel]

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 the Japanese char does not seem to be possible?


Did you select a 1-byte Japanese encoding on Windows?


Probably not. I try to have my German ä and the Japanese char, both in 
the name at the same time. (And maybe add some Arabic too).


So then you don't just want Japanese chars, you want full unicode, and 
preferably as one byte system. Do you know lazarus ? ( :-) ). Try to 
build the compiler in lazarus with the default utf8 code set in the 
resources screen, and then rebuild in a "cmd /w" prompt.


Disclaimer: all from theory, I never tried. Requires Win10 1905+

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

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

[Marco van de Voort via fpc-devel]

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?
___
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!

[Marco van de Voort via fpc-devel]

Op 2021-03-24 om 17:26 schreef Bart via fpc-devel:

 e placed the first release candidate of the Free Pascal Compiler

version 3.2.2 on our ftp servers.

I seem to mis the win32->wince crosscompiler at
ftp://ftp.freepascal.org/pub/fpc/beta/3.2.2-rc1/i386-win32/ ?


That was a TBD, since I didn't know if there were special prerequisites 
for it, but I just tried to generate it, and it seemed to go fine.



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

[Marco van de Voort via fpc-devel]

Op 2021-03-24 om 22:14 schreef Martin Frb via fpc-devel:


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?


Current know failures for linux/x86_64 are e.g.: 
(https://www.freepascal.org/testsuite/cgi-bin/testsuite.cgi?run1id=56==568619=1=1=Show%2FCompare)



id  filenameresult
4835 
 
	test/opt/tdfa11.pp 
 
	Failed to compile
4846 
 
	test/opt/tdfa8.pp 
 
	Failed, compilation successful
3305 
 
	test/packages/webtbs/tw14265.pp 
 
	Failed to compile
5630 
 
	test/tarray15.pp 
 
	Failed to run
2893 
 
	test/timplements4a.pp 
 
	Failed to run
2894 
 
	test/timplements4b.pp 
 
	Failed to run
5896 
 
	test/treadonlydata.pp 
 
	Failed to run
2460 
 
	test/tset6.pp 
 
	Failed to compile
5991 
 
	webtbs/tw14315b.pp 
 
	Failed to run
5223 
 
	webtbs/tw29893.pp 
 
	Failed to compile
2456 
 
	webtbf/tw3930a.pp 
 
	Failed, compilation successful



Which are 11 too, so I guess those are known ones.


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

[Marco van de Voort via fpc-devel]

Op 2021-03-24 om 12:20 schreef Pierre Muller via fpc-devel:



We have placed the first release candidate of the Free Pascal Compiler
version 3.2.2 on our ftp servers.

You can help improve the upcoming 3.2.2 release by downloading and
testing this release. If you want you can report what you have done 
here:

http://wiki.freepascal.org/Testers_3.2.2 or in the maillist.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

Downloads are available at the main FTP server and

ftp://freepascal.stack.nl/pub/mirrors/fpc/beta/3.2.2-rc1/


You need to open that directory to world!


That mirror doesn't exist anymore. Please use

ftp://ftp.freepascal.org/pub/fpc/beta/3.2.2-rc1/


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

[fpc-devel] FPC 3.2.2-RC1 release, now with working link!

[Marco van de Voort via fpc-devel]

Hello,

We have placed the first release candidate of the Free Pascal Compiler
version 3.2.2 on our ftp servers.

You can help improve the upcoming 3.2.2 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_3.2.2 or in the maillist.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

Downloads are available on the main FTP server at

ftp://ftp.freepascal.org/pub/fpc/beta/3.2.2-rc1/

The evaluation time frame for this release is at least two weeks, so 
bugreports within that period will be looked at before the final release 
is branched.


Enjoy!

The Free Pascal Compiler Team


    Free Pascal Compiler

    Version 3.2.2

** 



Free Pascal 3.2.2 is a minor release of the 3.2.x fixes branch. As such, 
it contains

mostly fixes for bugs discovered in the previous version, plus some updates
for included packages. In this case a target was also backported from 
trunk.


There are currently no known changes which might result in 
incompatibility to

the previous version 3.2.0.

The main highlights of this version:

Platforms:
  * New platform: aarch64-darwin
  * A new 32/64-bit combined installer for Windows.

Utilities:
  * fpcres provides support for compiling resources from *.rc files

Packages:
  * fcl-db extended with support for MySQL 8.0
  * fcl-passrc updates
  * pas2js updates
  * fpdoc updates
  * fcl-base includes new support for logging to StdOut and StdErr
  * rtl-extra includes improvements for Sockets

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

[fpc-devel] FPC 3.2.2-RC1 released!

[Marco van de Voort via fpc-devel]

Hello,

We have placed the first release candidate of the Free Pascal Compiler
version 3.2.2 on our ftp servers.

You can help improve the upcoming 3.2.2 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_3.2.2 or in the maillist.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.2

Downloads are available at the main FTP server and

ftp://freepascal.stack.nl/pub/mirrors/fpc/beta/3.2.2-rc1/

The evaluation time frame for this release is at least two weeks, so 
bugreports within that period will be looked at before the final release 
is branched.


Enjoy!

The Free Pascal Compiler Team


    Free Pascal Compiler

    Version 3.2.2

** 



Free Pascal 3.2.2 is a minor release of the 3.2.x fixes branch. As such, 
it contains

mostly fixes for bugs discovered in the previous version, plus some updates
for included packages. In this case a target was also backported from 
trunk.


There are currently no known changes which might result in 
incompatibility to

the previous version 3.2.0.

The main highlights of this version:

Platforms:
  * New platform: aarch64-darwin
  * A new 32/64-bit combined installer for Windows.

Utilities:
  * fpcres provides support for compiling resources from *.rc files

Packages:
  * fcl-db extended with support for MySQL 8.0
  * fcl-passrc updates
  * pas2js updates
  * fpdoc updates
  * fcl-base includes new support for logging to StdOut and StdErr
  * rtl-extra includes improvements for Sockets

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

Re: [fpc-devel] Different handling of try..except depending on OS?

[Marco van de Voort via fpc-devel]

Op 2020-12-10 om 21:57 schreef Sven Barth via fpc-devel:

Am 10.12.2020 um 20:54 schrieb Bart via fpc-devel:

No fpc in your linux vm ? I'm shocked... ;-)

Well, no trunk ;-)
On Windows I know how to easily switch between using compilers.
3.2.0 is in path and I have some batch files to change that for 3.0.4
and trunk respectively (only in the current console session).
I never had the courage to figure out how to do that on linux (in such
a way it does not interfere with my normal setup).
I use a script to change symlinks that are inside a directory that's 
in PATH.



In the past I used the -V parameter a lot.

 -V  Append '-' to the used compiler binary name (e.g. for version)

This allows to make symlinks like   e.g. ppcx64-3.0  to 
/usr/local/lib/fpc/3.0.4/ppcx64  and then compile with fpc -V3.0 etc.


Of course this meant that the fpc.cfg had to be carefully crafted with 
$FPCVERSION


The biggest drawback is that it only goes for the compiler not for the 
other binaries. AND it requires a parameter, but for a quick check with 
an old/release compiler that is enough.



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

Re: [fpc-devel] Problems building on i386-win32

[Marco van de Voort via fpc-devel]

Op 2020-11-25 om 18:10 schreef J. Gareth Moreton via fpc-devel:


That's the only useful stuff I found.  Sorry to sound like such a 
novice.  I have never come across this error before and am not sure 
how to resolve it without breaking something critical.


Easiest: do an install of the relevant oracle stuff on a scratch 
machine/VM, collect DLLs and put them in a directory.


Add that directory to the front of the %PATH% in the build script., and 
that dll will be found and not the system one.



(

All my path changing scripts have the same structure:


@echo off

if "%OLDPATH%" neq "" goto :nosave
set OLDPATH=%PATH%
:nosave
SET PATH=%OLDPATH%
PATH c:\pp32\bin\i386-win32;%PATH%

This allows to undo the change by just SET PATH=%OLDPATH%, and if I 
first use cygwin and then FPC, that they are not both in the path as the 
same time


)


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

Re: [fpc-devel] Problems building on i386-win32

[Marco van de Voort via fpc-devel]

Op 2020-11-25 om 00:37 schreef J. Gareth Moreton via fpc-devel:



This might be my own configuration, but can people check that 
i386-win32 works properly? I tried to build it to test one of my new 
optimisations, but got a failure when building the trunk (without my 
optimisations).


Building using "make all install OS_TARGET=win32 CPU_TARGET=i386 
FPC=C:\FPC\3.2.0\bin\i386-win32\fpc.exe" (since my machine is 64-bit 
Windows)


Compiles fine here (but I build with parallel options, and I don't have 
that dll).


Note that you seem to be building win32, but on a win64 system 
c:\windows\system32 is 64-bit ? It could be that the windows\system32 
part that you see is virtualized, but you could see if you check the 
type of that DLL.



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

Re: [fpc-devel] Github hosting of FPC utilities and [stable] sources

[Marco van de Voort via fpc-devel]

Op 22/10/2020 om 10:01 schreef Kevin Lyda via fpc-devel:

svn checkout https://svn.freepascal.org/svn/fpc/trunk fpc-svn  8.80s
user 7.43s system 49% cpu 32.790 total
du -sh *
626M fpc-git
728M fpc-svn


To compare sizes you need to specify the SVN version. Older versions 
iirc didn't compress pristines.



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

Re: [fpc-devel] Support for FreeBSD PowerPC

[Marco van de Voort via fpc-devel]

Op 2020-10-18 om 23:03 schreef Jonas Maebe via fpc-devel:



I’ve been able to create a cross compiler using the guidance and some
additional information.  But I’ve been unable to create the proper FPC
startup code (prt0.as) needed.

Any help would be appreciated.

I believe these files are generally created by disassembling the
system's crt1.o (objdump -d) and then changing the call(s) to the libc
intialisation code with calls to the FPC RTL intialisation code.
Afaik mostly gcc -S.  Trunk SVN also contains an untested and incomplete 
attempt at translating the C startup files to pascal.

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

Re: [fpc-devel] declaration of GetCharacterPlacementW(

[Marco van de Voort via fpc-devel]

Op 05/10/2020 om 01:31 schreef 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 


The var parameter generation suggests it is old, original API generation

Maybe the type changed in MSDN over time. Some things got flipped when 
the win9x and winnt winapi implementations were synchronized.


Please file a bug, and I'll add a correct overload (with int and without 
VAR param etc), and move this declaration to legacy


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

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Marco van de Voort via fpc-devel]

Op 2020-09-27 om 18:21 schreef Florian Klämpfl via fpc-devel:




So the question here is/are imho about the work it takes to amend the 
release-build process (i.e. update the scripts). And then the amount 
of extra time needed for each release (build and testing).


The thing is: we would distribute a compiler (the x86_64-win64 one) 
which claims to be able to compile to e.g. to x86_64-linux, but it 
would generate programs which might behave differently than natively 
compiled ones as float constants are handled internally different.


Or just block forbidden combinations wrt crossbuilding in the build 
system, rather than the release versions.

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

[fpc-devel] doc snapshot.

[Marco van de Voort via fpc-devel]

L.s.


To test the documentation generator fpdoc, I regenerated CHM 
documentation for the fixes (3.2.1) branch.


The documentation is generated with trunk fpdoc as of today, IOW with 
all the fcl-passrc modifications due to pas2js, which is the main reason 
for the test.


Location: http://www.stack.nl/~marcov/help/doc-chm202009.zip

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

Re: [fpc-devel] Merge request for 3.2 fixes

[Marco van de Voort]

Op 2020-07-25 om 21:51 schreef Benito van der Zander:



I looked in my repo, and they are in the list of regexpr fixes to merge.

http://www.stack.nl/~marcov/mergelogs32/regexr.html

If Michael "Ok"s them, I'll merge them/.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] [fpc-announce] FPC 3.2.0 released!

[Marco van de Voort]

Op 2020-07-03 om 19:18 schreef Keith Bowes via fpc-devel:

 Another thing was the Card function, which
I thought would be easy to do, as surely the code keeps track of how
many elements there are in a set, but if it does, I couldn't find it.


(Just a bit of fun, doesn't really answer your question, since obviously 
you'd need it in a ISO compatible mode. Also note that 3.2.0 branched 
over an year ago)


But 3.2.0 supports generic functions, and 3.0.0 already supported popcnt 
(https://www.freepascal.org/docs-html/rtl/system/popcnt.html).


But the syntax will be CARD(variable), and there are some minor 
things wrong with it: (anyone?)


- needs set type to be defined as type to reuse.

- what to do with a small registerable set, need const ref, but const 
[ref] is not yet supported in delphi mode?)


- and alignment requirements for the pointer walking.

- assumes unused bits in the last byte are 0. If that is unsure one 
could use the result of the AND 7 to make an and mask to mask out the 
unnecessary bits.



{$mode delphi}
{$pointermath on}

Function CARD(const a: T): Integer;
Var bits,dwords,rest,i : Integer;
    p: pbyte;
begin
  result:=0;
  p:=@a;
  bits:=(high(t)+1) ;
  dwords:=bits div 32;
  rest:=(bits mod 32); // bytes
  if (rest and 7)>0 then // round rest bits (and 7) up to whole byte (8)
    rest:=rest+8;
  rest:=rest shr 3; // bits -> bytes.
  for i:=0 to dwords-1 do
    begin
  result:=result +popcnt({unaligned?} pdword(p)^);
  inc(pdword(p));
    end;
  for i:=0 to rest-1 do
    begin
  result:=result +popcnt({unaligned?} pbyte(p)^);
  inc(p);
    end;
end;

Type TSettype = set of 0..80;

Var t : TSettype;
    i : Integer;
Begin
  t:=[];
  for i:=0 to 5 do
    Include(t,i*13);
  Writeln(CARD(t));
End.

I'll probably get back into it eventually, but I might have to redo what
I've already done, because conflicts in the Makefiles are pretty much a
certainty.  Personally, I'm nut sure why the Makefiles are included in
SVN; they should be generated `fpcmake -r` before compilation (or being
packed into a source tarball) to avoid this kind of thing.


But that would cause a bootstrap requirement on fpcmake, instead just 
the compiler. Note that recently, the generation date has been removed 
from the generate file to reduce conflicts.



Anyway, it'll be nice if we can get some more ISO 10206 features.  Some
have been popping up here and there over the years (string slices, the
** operator, WriteStr/ReadStr, etc), but a lot of useful features are
missing and seemingly have no equivalent in Borland's proprietary
dialect.


And of course schemata are the proverbial elephant in the room.


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

[fpc-devel] FPC 3.2.0 CHM docs updated.

[Marco van de Voort]

L.s.

Some problems with html and derived (CHM) documentation have come to light.

One of them was that images not generated by latex were not included in 
the documentation, specially the textmode IDE screenshots in the user 
manual.


This now has been fixed. Since documentation isn't branched in SVN, a 
handful of very minor fixes in SVN might be included too.


If you cache CHM docs for release purposes (lazarus, fpcdeluxe etc), 
please redownload.  The original archive has been renamed to 
doc-chmorig.zip in case somebody needs it.


Greetings

FPC core

p.s. the online html docs had the same problem, and also the railroad 
diagrams in the ref manual were corrupt, this was independently fixed by 
Michael.



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

[fpc-devel] HEADS UP: fixes updated to 3.2.1

[Marco van de Voort]

Now FPC 3.2.0 has been released, the version of the fixes branch has 
been updated to 3.2.1. If you maintain scripts to compile/install the 
fixes branch, they might need adjustment


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

[fpc-devel] FPC 3.2.0 released!

[Marco van de Voort]

Hello,

Finally, the Free Pascal 3.2.0 release is available from our servers and 
from sourceforge.


Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.0.

For an overview of what is new see

https://wiki.freepascal.org/FPC_New_Features_3.2

The website has been update for the major targets and work is still 
being done for the rest.


All downloads are available at the main FTP server and sourceforge.

https://sourceforge.net/projects/freepascal/files/

ftp://ftp.freepascal.org/pub/fpc/dist/3.2.0/

Enjoy!

The Free Pascal Compiler Team



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

Re: [fpc-devel] JWA 64-bit struct packing

[Marco van de Voort]

Op 2020-05-14 om 17:03 schreef Henry Vermaak via fpc-devel:

The original headers only did 32-bit. Over the years some 64-bit
corrections have been added. This process is ongoing, so please make
sure you use the newest version.

Grepping for align|packrecords give exactly the same results in trunk,
afaics.  jwawindows.pas explicitly sets align 4.


jwawindows.pas
    {$ALIGN 4}
{$ALIGN 4}
jwawinldap.pas
{$ALIGN ON}
jwawinsock2.pas
{$ALIGN 4}
jwaws2atm.pas
{$ALIGN ON}
jwaws2spi.pas
{$ALIGN OFF}
{$ALIGN ON}

But yeah, that looks bad.




I'm a bit loath to try to fix this with big, overarching $packrecords,
because the winapi actually sometimes uses packrecords C and sometimes
packrecords 8.

So why is rtl/win*/* full of packrecords c?  These pages say that the
Windows API expect 8:

https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers#controlling-structure-packing
https://docs.microsoft.com/en-gb/cpp/build/reference/zp-struct-member-alignment


Those are probably the exceptions then. But jwa* is delphi compat, so 
can't use $PUSH/$POP, so changing defaults is less useful, since it will 
be undone at the first exception



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

Re: [fpc-devel] JWA 64-bit struct packing

[Marco van de Voort]

Op 2020-05-14 om 15:53 schreef Henry Vermaak via fpc-devel:

I'm having some crashes and errors from 64-bit Windows builds that use
the JWA units.  I've tracked it down to record alignment (the 32-bit
version works fine, so it's the first place I looked).  I notice that
there's no {$packrecords c} anywhere (or alternatively {$align 8} for
64-bit).  Am I missing something?  I'm having trouble believing that
no one has found this before.


The original headers only did 32-bit. Over the years some 64-bit 
corrections have been added. This process is ongoing, so please make 
sure you use the newest version.


I'm a bit loath to try to fix this with big, overarching $packrecords, 
because the winapi actually sometimes uses packrecords C and sometimes 
packrecords 8.


Similar attempts in the normal windows headers were cumbersome, so we 
are dealing with it on a case by case basis.


If you have problems with certain structures, AND you have tested with 
trunk or FPC 3.2.0rc1, please file a bug.


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

Re: [fpc-devel] r45217 breaks Lazarus compile

[Marco van de Voort]

Op 2020-05-05 om 11:08 schreef Sven Barth via fpc-devel:


ForDebugging is just one of the purposes, and TThread.NameThread is
double, since it is a property of a thread, what else would you
give a name.


As Marco said,


? huh ?

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

Re: [fpc-devel] FPC and Z80

[Marco van de Voort]

Op 2020-04-27 om 21:24 schreef Florian Klämpfl:
Well, for 6502 working 16-bit ptr indirect via volatile zp memory 
locations needs to be implemented anyway :-)


Does that CPU have no hardware stack at all, or only limited (128/256 
bytes or so?)


It has a full stack but too little registers to use it efficiently for 
local variables: it has 3 8 bit registers pair plus accumulator (so 7 
8 bit registers), 


Then you need a parallel software stack for parameters and local vars, 
and keep the hw stack for return addresses only.


But like with the c=64 without 16-bit regs you probably need some form 
of indirect addressing via zeropage base pointers to access that stack( 
if>8bit).  IIRC the 6502 had very little free ZPs, but a lot more if you 
can reuse the locations used by the interpreter (e.g. backup/restore if 
you want to be able to return to basic)


two of them can be used as pairs for indirect addressing, so this 
makes life very hard


That is already more than the 6502 has.  Afaik the instruction pointer 
is the only 16-bit one. But if an basic interpreter can do it, so can a 
compiled program?



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

Re: [fpc-devel] FPC and Z80

[Marco van de Voort]

Op 2020-04-27 om 18:28 schreef Florian Klaempfl:



I have no idea, but quickly read through some docs, and it seems the
GameBoy CPU doesn't have IX/IY registers, which seems to be very 
useful to
implement some of the more complex references handling, according to 
what
Nikolay wrote earlier. 


Yes. IX and IY are the key for the FPC Z80 port. Without them it's 
getting really difficult. And I suspect we need to work without a 
normal stack but allocate local variables globally, so basically no 
recursion will be possible.


Well, for 6502 working 16-bit ptr indirect via volatile zp memory 
locations needs to be implemented anyway :-)


Does that CPU have no hardware stack at all, or only limited (128/256 
bytes or so?)



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

Re: [fpc-devel] New feature announcement: constant parameters for generics

[Marco van de Voort]

Op 2020-04-26 om 11:48 schreef Sven Barth via fpc-devel:


Jeppe had provided a potential usecase on the core mailing list in 
October '18. His example is not useable as-is, but to give you an idea:


 As the compiler can inline all this, the writing of maintainable, 
hardware agnostic frameworks for embedded controllers becomes easier.


(Actually you'd probably want to use atomic RMW operations, because 
otherwise a write from a thread or interrupt routine could be 
overwritten, even if it was not on bits that clash)


A further example could be to determine the size of a hash table: 
Determining that at compile time instead of runtime might allow for 
better code. At the same time the user of that code would still be 
able to influence it.


Yup. My Genlight sorted stringlist could also use it for tuning. To 
workaround the classic tstringlist ordered insertion limit, it uses an 
(dyn) array of small arrays to store the strings, which postpones the 
inevitable with about a magnitude 10-20.


The constant would be the size of the deeper array, now a weighted value 
1024.


Larger (e.g. 4096) means less memory overhead, faster iteration, but 
with slower (random) insertion performance, which can be perfectly fine 
if your datasource is mostly in order + few mutations.



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

Re: [fpc-devel] New feature announcement: constant parameters for generics

[Marco van de Voort]

Op 2020-04-26 om 11:02 schreef Michael Van Canneyt:


As the original author, can you say something about the intended use 
of this feature ?


It was meant for a pretty narrow use of array types. If I knew how 
much work it would be to implement I probably would have not done it. 
:P I personally wanted it for static array lists that had methods 
like Add/Delete.


Fixed-length arrays are the only practical use I can think of.


Valuetype sets of enum>256 elements.  Type T is the enum, const is 
ord(high(enum) div 32)+1


De const is then a high bound of the array, type T is only used to 
implement the operators and methods.



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

[fpc-devel] FPC 3.2.0RC1 released!

[Marco van de Voort]

Hello,

We have placed the first release candidate of the Free Pascal Compiler
version 3.2.0 on our ftp servers.

You can help improve the upcoming 3.2.0 release by downloading and
testing this release. If you want you can report what you have done here:
http://wiki.freepascal.org/Testers_3.2.0 or in the maillist.

Changes that may break backwards compatibility will be documented at:
http://wiki.freepascal.org/User_Changes_3.2.0

Downloads are available at the main FTP server,

ftp://ftp.freepascal.org/pub/fpc/beta/3.2.0-rc1/

Enjoy!

The Free Pascal Compiler Team

For an overview of what is new see

https://wiki.freepascal.org/FPC_New_Features_3.2

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

Re: [fpc-devel] Request for LEB128 discussion again

[Marco van de Voort]

Op 2020-03-19 om 17:00 schreef J. Gareth Moreton:

Hi everyone,

How is everyone doing? Noticed it's a bit quiet on this mailing list, 
so I hope everyone is still alive!


This one has some slightly selfish connotations, because I'm having a 
lot of problems with disk full errors on my development platform when 
working with FPC (and running "make distclean" on my FPC source 
directory freed up nearly 700 MB of storage).


(don't forget to once a year or so to svn cleanup the repos, this 
vacuums pristines)


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