Re: [fpc-devel] Test suite error wrong PPU

2022-06-24 Thread Sven Barth via fpc-devel
Hairy Pixels schrieb am Fr., 24. Juni 2022, 03:45: > > > > On Jun 23, 2022, at 11:52 PM, Sven Barth > wrote: > > > > As you can see at the end (see below) it falls back to 3.2.2 at the end. > What commands did you execute to build FPC itself? > > > > I have no idea what it did that. I’ve done

Re: [fpc-devel] Test suite error wrong PPU

2022-06-23 Thread Sven Barth via fpc-devel
Hairy Pixels via fpc-devel schrieb am Do., 23. Juni 2022, 04:08: > I usually solve this by deleting the units folder but for some reason > after pulling from main it simply won’t build. Can anyone explain why the > PPU version is wrong? It’s all building from the same source directory so > the

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

2022-06-20 Thread Sven Barth via fpc-devel
Am 03.06.2022 um 14:32 schrieb 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

Re: [fpc-devel] Generic keywords mode switch

2022-06-13 Thread Sven Barth via fpc-devel
Hairy Pixels schrieb am Mo., 13. Juni 2022, 05:30: > Me and Sven had planned this a couple years ago and I finally got around > to it this weekend since it was pretty trivial. The reason for this being > we wanted a way to disable the generic keywords in ObjFPC mode. The > solution is to

Re: [fpc-devel] DEBUG_NODE_XML broken

2022-05-26 Thread Sven Barth via fpc-devel
Am 27.05.2022 um 04:41 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, Building the compiler with -dDEBUG_NODE_XML got broken recently: C:/lazarus/fpc/3.2.0/bin/x86_64-win64/ppcx64.exe -Ur -Xs -O2 -n -Fux86_64 -Fusystems

Re: [fpc-devel] Functors

2022-05-26 Thread Sven Barth via fpc-devel
Am 26.12.2021 um 02:16 schrieb Blaise--- via fpc-devel: Important design points: 1) Applying round brackets to instances does not collide with the existing syntax; 2) Naturally, helpers are able to turn helpees into functors; 3) Operator () cannot be applied to types -- that would clash with

Re: [fpc-devel] $modeswitch Closures

2022-05-26 Thread Sven Barth via fpc-devel
Am 25.12.2021 um 20:22 schrieb Blaise--- via fpc-devel: The attached modeswitch_closures.patch introduces {$modeswitch Closures}; it is included in {$mode Delphi}. There is a distinction between anonymous routines (defined in-place, without a name) and closures (capture the context they are

Re: [fpc-devel] Initialising method pointers with class methods

2022-05-26 Thread Sven Barth via fpc-devel
Am 24.12.2021 um 02:27 schrieb Blaise--- via fpc-devel: DCC allows the subj (provided that the class type is known at compile time), FPC does not. The attached init_methptr_with_classmeth.patch implements this feature. ---8<--- type C = class class procedure Foo; end; class

Re: [fpc-devel] Assigning class methods, accessed via a class reference type, to procvars

2022-05-26 Thread Sven Barth via fpc-devel
Am 22.12.2021 um 19:16 schrieb Blaise--- via fpc-devel: 1) The attached metaclass_meth_to_procvar-1.patch fixes the internal error reported for: [ICE] Assigning class methods, accessed via a class reference type, to incompatible procvars ---8<--- type C = class class procedure

Re: [fpc-devel] Assigning instance methods, accessed via a type, to method pointers

2022-05-26 Thread Sven Barth via fpc-devel
Am 23.12.2021 um 19:13 schrieb Blaise--- via fpc-devel: Subj silently produces invalid codegen: ---8<--- var Z: procedure of object; type R = record procedure Foo; end; procedure R.Foo; begin end; type O = object procedure Foo; end; procedure O.Foo; begin end; type C = class   

Re: [fpc-devel] Parsing procedural type and method directives

2022-05-26 Thread Sven Barth via fpc-devel
Am 21.12.2021 um 21:37 schrieb Blaise--- via fpc-devel: 1) The following three routines: pdecsub.pas!parse_parameter_dec pdecvar.pas!maybe_parse_proc_directives ptype.pas!read_named_type\procvar_dec create a dummy typesym for the procdef, for the sole purpose of invoking

Re: [fpc-devel] Thoughts: Make FillChar etc. an intrinsic for specialised performance potential

2022-04-19 Thread Sven Barth via fpc-devel
Stefan Glienke via fpc-devel schrieb am Di., 19. Apr. 2022, 12:38: > If you want to zero small records more efficiently it might be better > using Default(t) for that and looking at optimizing the code the compiler > generates for that as it seems it produces an empty temp variable which it >

Re: [fpc-devel] Incompatible assignments but no compile error (char array and shortstring)

2022-04-17 Thread Sven Barth via fpc-devel
Am 16.04.2022 um 22:35 schrieb Wayne Sherman via fpc-devel: Tested with fpc 3.3.1 trunk (as of 2022-Mar-12) and 3.2.2 stable. Ubuntu 20.04 64-bit Good compile time error checking is one of the wonderful things about Pascal. But some char array and shortstring assignments which are not size

Re: [fpc-devel] Thoughts: Make FillChar etc. an intrinsic for specialised performance potential

2022-04-17 Thread Sven Barth via fpc-devel
Florian Klämpfl via fpc-devel schrieb am Sa., 16. Apr. 2022, 21:00: > > > > Am 16.04.2022 um 01:26 schrieb J. Gareth Moreton via fpc-devel < > fpc-devel@lists.freepascal.org>: > > > > Hi everyone, > > > > This is something that sprung to mind when thinking about code speed and > the like, and

Re: [fpc-devel] Thoughts: Make FillChar etc. an intrinsic for specialised performance potential

2022-04-16 Thread Sven Barth via fpc-devel
J. Gareth Moreton via fpc-devel schrieb am Sa., 16. Apr. 2022, 01:33: > Actual Pascal calls to FillChar would not change in any way and so > theoretically it won't break existing code. The only drawback is that > the intrinsic and the internal System functions would have to be named > the same

Re: [fpc-devel] Thoughts: Make FillChar etc. an intrinsic for specialised performance potential

2022-04-16 Thread Sven Barth via fpc-devel
Benito van der Zander via fpc-devel schrieb am Sa., 16. Apr. 2022, 15:43: > Hi, > > it could always inline it. > > For small sizes do that mov and for large sizes do rep stosb on x86. It is > very fast nowadays. Faster than FillChar on my Intel laptop. (except for > mid sizes like 128 bytes) >

Re: [fpc-devel] Problems with MM types (__m128 etc).

2022-04-06 Thread Sven Barth via fpc-devel
Am 06.04.2022 um 20:32 schrieb J. Gareth Moreton via fpc-devel: Another problem... I've tried to declare an ADDPD intrinsic as follows: function x86_addpd(r0, r1: __m128d): __m128d; [INTERNPROC: fpc_in_x86_addpd]; I thought using __m128d instead of __m128 was fairly logical since ADDPD

Re: [fpc-devel] Questions about cross-compiling (z80)

2022-02-12 Thread Sven Barth via fpc-devel
BogDan schrieb am Sa., 12. Feb. 2022, 13:23: > Hi, > > > On Saturday, February 12, 2022, 11:23:40 AM GMT+2, Sven Barth < > pascaldra...@googlemail.com> wrote: > > > BogDan via fpc-devel schrieb am Sa., 12. > Feb. 2022, 10:18: > > Also, everything that is not used by the application it should be

Re: [fpc-devel] Questions about cross-compiling (z80)

2022-02-12 Thread Sven Barth via fpc-devel
BogDan via fpc-devel schrieb am Sa., 12. Feb. 2022, 10:18: > Also, everything that is not used by the application it should be stripped > by the linker (if it has one). Again I'd like to highlight that I'm new to > fpc, last time I used pascal it was over 20 years ago :) . > The linker can only

Re: [fpc-devel] Questions about cross-compiling (z80)

2022-02-11 Thread Sven Barth via fpc-devel
BogDan schrieb am Fr., 11. Feb. 2022, 22:20: > Hi, > > > Thanks a lot for your quick reply. > > Adding ihxutil to path fixed the problem. > But the size problem is stil there, a simple 2 lines of code "begin; > end." generates over 32k of code. That code should not generate more than > 8 bytes

Re: [fpc-devel] Questions about cross-compiling (z80)

2022-02-11 Thread Sven Barth via fpc-devel
Tomas Hajny via fpc-devel schrieb am Fr., 11. Feb. 2022, 17:24: > On 2022-02-11 14:14, Sven Barth via fpc-devel wrote: > > BogDan via fpc-devel schrieb am Fr., > > 11. Feb. 2022, 11:09: > > . > . > >> It seems is an IHX format not tzx > >> Also the

Re: [fpc-devel] Questions about cross-compiling (z80)

2022-02-11 Thread Sven Barth via fpc-devel
BogDan via fpc-devel schrieb am Fr., 11. Feb. 2022, 11:09: > Hello, > > According to https://wiki.freepascal.org/Z80 fpc is able to compile > pascal code for z80. > Sadly I'm a newbie on fpc, therefore I have a few questions: > > 1. I changed a bit the build script from >

Re: [fpc-devel] Current state of atari port

2022-02-10 Thread Sven Barth via fpc-devel
Am 11.02.2022 um 03:59 schrieb Karoly Balogh: Hi, On Thu, 10 Feb 2022, Sven Barth via fpc-devel wrote: Thorsten Otto via fpc-devel schrieb am Do., 10. Feb. 2022, 15:47: Cause in the variant you mentioned where would the allocated memory be stored? I'm not that familiar with ObjectGEM yet

Re: [fpc-devel] Current state of atari port

2022-02-10 Thread Sven Barth via fpc-devel
Am 10.02.2022 um 19:22 schrieb Thorsten Otto via fpc-devel: On Donnerstag, 10. Februar 2022 19:13:15 CET Sven Barth via fpc-devel wrote: > And how does one work with the created instance? How does one release it? Do > you have an example for that? Maybe some examples of ObjectGEM

Re: [fpc-devel] Current state of atari port

2022-02-10 Thread Sven Barth via fpc-devel
Thorsten Otto via fpc-devel schrieb am Do., 10. Feb. 2022, 15:47: > On Donnerstag, 10. Februar 2022 14:21:54 CET Sven Barth via fpc-devel > wrote: > > > Anything else does not make sense. > > > > > > Cause in the variant you mentioned where would the allocated me

Re: [fpc-devel] Current state of atari port

2022-02-10 Thread Sven Barth via fpc-devel
Thorsten Otto via fpc-devel schrieb am Do., 10. Feb. 2022, 13:00: > - when constructing objects, ObjectGEM uses contructs like > > new(PGroupBox, init(...) > > Such constructs are not supported by FreePascal, you have to assign the > result to some variable (i think that is also an

Re: [fpc-devel] Questions regarding m68k-atari target

2022-02-07 Thread Sven Barth via fpc-devel
Thorsten Otto via fpc-devel schrieb am Mo., 7. Feb. 2022, 13:00: > In the long term, it would be nice to have some automatic selection of the > correct libraries. Otherwise it will not be possible to produce 68k > binaries with a compiler that was compiled for 68020, since that will still > pull

Re: [fpc-devel] Questions regarding m68k-atari target

2022-01-29 Thread Sven Barth via fpc-devel
Am 29.01.2022 um 09:24 schrieb Thorsten Otto via fpc-devel: On Freitag, 28. Januar 2022 20:21:03 CET Karoly Balogh wrote: > a fixed GAS/LD support would be nice, of > course. Yes, but currently i'm a bit lost here. Since that combination currently does not support "smart linking", i guess

Re: [fpc-devel] Questions regarding m68k-atari target

2022-01-28 Thread Sven Barth via fpc-devel
Am 28.01.2022 um 18:04 schrieb Thorsten Otto via fpc-devel: The error number comes from def_system_macro, when it is invoked with an empty name. The crash seems to happen in system.o, during initalization. The external name of the procedure is 'SYSTEM_$$_RECORDRTTI$POINTER$POINTER$TRTTIPROC'

Re: [fpc-devel] Questions regarding m68k-atari target

2022-01-25 Thread Sven Barth via fpc-devel
Thorsten Otto via fpc-devel schrieb am Di., 25. Jan. 2022, 14:45: > >If I'm not mistaken, GCC for > > >Atari used to have some tool like this? Brownout, maybe? > > > > Yes, but i never used that "brown" tool. For one, i don't like its > confusing naming convention (depending on gcc version, it

Re: [fpc-devel] Questions regarding m68k-atari target

2022-01-25 Thread Sven Barth via fpc-devel
Thorsten Otto via fpc-devel schrieb am Di., 25. Jan. 2022, 13:03: > On Dienstag, 25. Januar 2022 12:22:33 CET Karoly Balogh wrote: > > > Hi, > > > > > > On Tue, 25 Jan 2022, Thorsten Otto via fpc-devel wrote: > > > > Yes, a.out support (which is used on Atari) has been dropped in 2.31. > > > >

Re: [fpc-devel] Questions regarding m68k-atari target

2022-01-25 Thread Sven Barth via fpc-devel
Thorsten Otto via fpc-devel schrieb am Di., 25. Jan. 2022, 10:54: > > the prefix $CPU-$OS is just the default prefix for every cross > > > compiling, if you need an other, you can supply it with e.g. > > > -XPm68k-atari-mint- > > > > Yes, found that already. But there is also at least one

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

2022-01-14 Thread Sven Barth via fpc-devel
Mattias Gaertner via fpc-devel schrieb am Fr., 14. Jan. 2022, 10:01: > On Fri, 14 Jan 2022 07:32:59 +0100 > Sven Barth via fpc-devel wrote: > > >[...] > > Just FYI what Delphi writes in their documentation ( > > > https://docwiki.embarcadero.com/RADStudio/

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

2022-01-13 Thread Sven Barth via fpc-devel
Am 14.01.2022 um 05:20 schrieb Ben Grasset via fpc-devel: On Thu, Jan 13, 2022 at 9:20 AM Travis Siegel via fpc-devel wrote: I wasn't aware of the whole MS not supporting the FPU thing, that was the missing puzzle piece. It's not a realistic concern in actuality. There's a reason 

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

2022-01-13 Thread Sven Barth via fpc-devel
Am 14.01.2022 um 03:15 schrieb Ben Grasset via fpc-devel: On Thu, Jan 13, 2022 at 9:48 AM Nikolay Nikolov via fpc-devel wrote: What do other win64 compilers do? Do they generate x87 FPU code for 64-bit Windows? Yes. Given the following: #include long double do_three(long double

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

2022-01-12 Thread Sven Barth via fpc-devel
Am 12.01.2022 um 19:26 schrieb Martin Frb via fpc-devel: On 12/01/2022 18:48, Sven Barth via fpc-devel wrote: [2] From the users view "random", in that the user can not predict all the factors that will affect the selection. Currently the user must be prepared for

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

2022-01-12 Thread Sven Barth via fpc-devel
Martin Frb via fpc-devel schrieb am Mi., 12. Jan. 2022, 18:06: > On 12/01/2022 17:31, Tomas Hajny via fpc-devel wrote: > > On 2022-01-12 16:03, Martin Frb via fpc-devel wrote: > >> > >> > >> But, if any change to the code (not even necessarily a functional > >> change) would allow the compiler

Re: [fpc-devel] Assembler file option (-a)

2021-12-31 Thread Sven Barth via fpc-devel
Christo Crause via fpc-devel schrieb am Fr., 31. Dez. 2021, 16:58: > On Fri, Dec 31, 2021 at 4:41 PM Marco Borsari via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Hi, >> on Linux with FPC 3.2.2 the executable size of programs compiled with >> fpc -On -a (tried with n 2 or 4) >> is

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

2021-12-19 Thread Sven Barth via fpc-devel
Ben Grasset via fpc-devel schrieb am So., 19. Dez. 2021, 08:33: > To be very clear, to me, this is absolutely nothing more than just a > matter of building the compiler completely normally. It takes like two > minutes all-in. I don't really get why the person who uploads the 32-bit > Windows

Re: [fpc-devel] Attn: Sven Can not use "specialize" to resolve forward declaration

2021-12-08 Thread Sven Barth via fpc-devel
Martin Frb via fpc-devel schrieb am Do., 9. Dez. 2021, 00:15: > https://gitlab.com/freepascal.org/fpc/source/-/issues/39459 > You wrote > >> No, this can not and this will never work. When a generic parameter has > a constraint that constraint *must* be adhered to and a forward > declaration is

Re: [fpc-devel] RTTI status in 3.2.0 and 3.2.2

2021-09-19 Thread Sven Barth via fpc-devel
Gennady Agranov via fpc-devel schrieb am Sa., 18. Sep. 2021, 01:11: > Hi, > > I have Delphi RTTI code that takes record's type info, finds method and > calls it... > > The code does not seem to work in 3.2.0 (SEGV) > > Should it work? > > Should I try 3.2.2 or there are other ways to call record

Re: [fpc-devel] Undefined symbol during linking - any suggestions?

2021-09-07 Thread Sven Barth via fpc-devel
Am 08.09.2021 um 06:33 schrieb Gennady Agranov via fpc-devel: Hi, linker complains about undefined symbol  .Lj3016 I checked *.s files and found that one file has no label .Lj3016 but has following line:     leaq   .Lj3016(%rip),%rdx Am I correct that that this *.s file should also

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

2021-08-24 Thread Sven Barth via fpc-devel
Bart via fpc-devel schrieb am Di., 24. Aug. 2021, 06:31: > On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel > wrote: > > > Just move common.dll from SysWOW64 to system32. The file is placed > wrongly > > by some installer. > > If I understand Tomas correctly then that would not make

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

2021-08-23 Thread Sven Barth via fpc-devel
Am 23.08.2021 um 19:33 schrieb Bart via fpc-devel: On Mon, Aug 23, 2021 at 7:16 PM Bart wrote: I tried to build with only the path to the starting compiler in %PATH%: PATH /devel/fpc/3.2.2/bin/i386-Win32 make clean make all OPT=... That failed on make clean: That error goes away if I add

Re: [fpc-devel] Build failure in Fedora 35 due to glibc 2.34 code hardening

2021-08-08 Thread Sven Barth via fpc-devel
Am 08.08.2021 um 10:06 schrieb Florian Klämpfl via fpc-devel: Am 07.08.2021 um 16:59 schrieb Mattia Verga via fpc-devel : Fedora has recently moved to using glibc 2.34. That caused Free Pascal Compiler to stop building with the following output: /usr/bin/ld:

Re: [fpc-devel] Different computation precision in 32-bit and 64-bit app

2021-07-30 Thread Sven Barth via fpc-devel
NetSpirit via fpc-devel schrieb am Fr., 30. Juli 2021, 15:37: > This code gives distinct results when compiled for Win32 and Win64 > - Win32: 49744125 > - Win64: 49744124.999 > > procedure Test; > var > D: Double; > begin > D := 3 * (exp(3 * ln(255))); > WriteLn('Result: ' +

Re: [fpc-devel] TDef flags

2021-07-04 Thread Sven Barth via fpc-devel
Am 04.07.2021 um 12:59 schrieb J. Gareth Moreton: Okay, okay. Not too harsh, please. Better to stop the intention of modifying defs before you can get a taste for them. :P I feel I don't yet know enough about defs and generics to properly fix this bug, only that the defs used aren't

Re: [fpc-devel] TDef flags

2021-07-04 Thread Sven Barth via fpc-devel
Am 03.07.2021 um 15:01 schrieb J. Gareth Moreton via fpc-devel: Hi everyone, I'm trying to fix i38827, and am trying a few things.  One thing I've noticed is that some specializations have both the df_generic and df_specialization flags set, and the def missing from the debug information

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

2021-06-30 Thread Sven Barth via fpc-devel
J. Gareth Moreton via fpc-devel schrieb am Do., 1. Juli 2021, 01:29: > Ah curses. I fear it was something I did. I don't like the idea of > stepping through each revision until we find one that works. > That's where bisecting comes into play: find a revision where it is working (or not

Re: [fpc-devel] FPC & Lazarus moving to gitlab

2021-06-22 Thread Sven Barth via fpc-devel
Am 23.06.2021 um 00:09 schrieb Ryan Joseph via fpc-devel: On Jun 22, 2021, at 4:02 PM, Sven Barth wrote: The plan has *never* been GitHub. The original plan was self hosted with a *mirror* on GitHub. Now we'll instead use GitLab as main repository with a mirror on GitHub. How does the

Re: [fpc-devel] FPC & Lazarus moving to gitlab

2021-06-22 Thread Sven Barth via fpc-devel
Ryan Joseph via fpc-devel schrieb am Di., 22. Juni 2021, 23:49: > > > > On Jun 22, 2021, at 10:05 AM, Michael Van Canneyt via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > The date for the final conversion has been established as the weekend of > > 17/18 july. People that wish to

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

2021-05-30 Thread Sven Barth via fpc-devel
Am 30.05.2021 um 11:39 schrieb Don Alfredo via fpc-devel: https://synopse.info/forum/viewtopic.php?id=5894 I'm already working on a fix for this, cause I had seen that thread a few days ago already. It would have been nice however if you had

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

2021-05-30 Thread Sven Barth via fpc-devel
Am 30.05.2021 um 00:53 schrieb 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

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

2021-05-19 Thread Sven Barth via fpc-devel
Am 19.05.2021 um 22:42 schrieb Martin Frb: On 19/05/2021 22:10, Sven Barth wrote: Am 18.05.2021 um 15:24 schrieb Martin Frb via fpc-devel: I was looking at TypeInfo (based on 3.2.2rc) . fpc_3.2.2\source\tests\webtbs\tw12038.pp    line 194    procedure DisplayDetails(Informations :

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

2021-05-19 Thread Sven Barth via fpc-devel
Am 18.05.2021 um 17:33 schrieb Martin Frb via fpc-devel: On 18/05/2021 15:50, Martin Frb via fpc-devel wrote: On 18/05/2021 15:24, Martin Frb via fpc-devel wrote: line 632  unit TypInfo     tkMethod:   followed by   ResultType : ShortString // for

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

2021-05-19 Thread Sven Barth via fpc-devel
Am 18.05.2021 um 15:50 schrieb Martin Frb via fpc-devel: On 18/05/2021 15:24, Martin Frb via fpc-devel wrote: I was looking at TypeInfo (based on 3.2.2rc) line 632  unit TypInfo     tkMethod:   followed by   ResultType : ShortString // for

Re: [fpc-devel] TypeInfo RTTI / possible inconsistency

2021-05-19 Thread Sven Barth via fpc-devel
Am 18.05.2021 um 15:24 schrieb Martin Frb via fpc-devel: I was looking at TypeInfo (based on 3.2.2rc) line 632  unit TypInfo     tkMethod:   (MethodKind : TMethodKind;    ParamCount : Byte;    ParamList : array[0..1023] of Char {in

Re: [fpc-devel] Implicit function specialization precedence

2021-05-16 Thread Sven Barth via fpc-devel
Am 15.05.2021 um 20:08 schrieb Ryan Joseph via fpc-devel: On May 15, 2021, at 10:49 AM, Ryan Joseph wrote: Also it looks like ChangeOwnerAndName isn't making the compiler happy. Sorry for the noise, I figured out it was because the name had spaces. How should I make the name then? I'm

Re: [fpc-devel] Implicit function specialization precedence

2021-05-16 Thread Sven Barth via fpc-devel
Am 15.05.2021 um 18:27 schrieb Ryan Joseph via fpc-devel: On May 13, 2021, at 2:38 PM, Sven Barth wrote: Ah, you need to use ChangeOwnerAndName then and simply pass in the same name you used for the constructor (cause otherwise it tries to use the name that is currently stored in the

Re: [fpc-devel] Implicit function specialization precedence

2021-05-13 Thread Sven Barth via fpc-devel
Am 12.05.2021 um 17:50 schrieb Ryan Joseph via fpc-devel: On May 9, 2021, at 1:30 AM, Sven Barth wrote: Essentially it will boil down to sym.ChangeOwner(pd.parast) However you need to keep the Owner (which is different from what you change with ChangeOwner) different as otherwise

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-11 Thread Sven Barth via fpc-devel
Am 10.05.2021 um 23:18 schrieb Ryan Joseph via fpc-devel: On May 10, 2021, at 3:05 PM, Sven Barth via fpc-devel wrote: Why should they? You pass the reference to a non-reference counted parameter/field/variable, the reference count is increased and then what? It sits

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-10 Thread Sven Barth via fpc-devel
Am 09.05.2021 um 17:14 schrieb Ryan Joseph via fpc-devel: On May 9, 2021, at 3:40 AM, Sven Barth wrote: === code begin === {$mode objfpc} type TTest = class protected procedure DoSomething; end; TTestSub = class refcounted(TTest) public procedure Test; end;

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-10 Thread Sven Barth via fpc-devel
Am 09.05.2021 um 16:58 schrieb Ryan Joseph via fpc-devel: On May 9, 2021, at 3:40 AM, Sven Barth wrote: It seems that you don't work much with classes then. If one disallows the assignment of a reference counted class to a non-reference counted one then you can't use e.g.

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-09 Thread Sven Barth via fpc-devel
Am 08.05.2021 um 19:38 schrieb Ryan Joseph via fpc-devel: On May 8, 2021, at 11:18 AM, Sven Barth wrote: It's not about reference counted classes vs. managed records, but about whether it's *per type* or *per variable*, the implementation details are completely irrelevant for now. So the

Re: [fpc-devel] Implicit function specialization precedence

2021-05-09 Thread Sven Barth via fpc-devel
Ryan Joseph via fpc-devel schrieb am Sa., 8. Mai 2021, 22:33: > > > > On May 8, 2021, at 12:04 PM, Sven Barth > wrote: > > > > You need to use ChangeOwner as well, but as I wrote you need to pay > attention for which created symbol you do it at what time. > > Ok, maybe this is what I got wrong

Re: [fpc-devel] Implicit function specialization precedence

2021-05-08 Thread Sven Barth via fpc-devel
Am 22.04.2021 um 17:52 schrieb Ryan Joseph via fpc-devel: On Apr 16, 2021, at 11:35 AM, Ryan Joseph wrote: Got this all integrated and put up the changes to https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another final review. :) The next thing to do now is to handle a

Re: [fpc-devel] Implicit function specialization precedence

2021-05-08 Thread Sven Barth via fpc-devel
Am 06.05.2021 um 17:33 schrieb Ryan Joseph via fpc-devel: I found something sneaky I'd like to confirm before I decide what to do about it. 1) "T" in TAnyClass is specialized as Integer from the first parameter with TSomeClass (which is TAnyClass). 2) "U" is getting specialized as String by

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-08 Thread Sven Barth via fpc-devel
Am 08.05.2021 um 18:23 schrieb Ryan Joseph via fpc-devel: On May 8, 2021, at 7:59 AM, Sven Barth via fpc-devel wrote: It has the exact same problems that my branch had (especially the interaction of reference counted instances with non-reference counted ones). Using a variable/parameter

Re: [fpc-devel] Defer keyword

2021-05-08 Thread Sven Barth via fpc-devel
Am 07.05.2021 um 17:57 schrieb Ryan Joseph via fpc-devel: On May 7, 2021, at 2:46 AM, Sven Barth via fpc-devel wrote: I cannot speak for others, but I think 90% of potential use cases for ref counting would be covered like this in my code: objects that only live inside a procedure. I

Re: [fpc-devel] Defer keyword

2021-05-08 Thread Sven Barth via fpc-devel
Am 07.05.2021 um 17:40 schrieb Benito van der Zander via fpc-devel: The introduction of generics and their abundant use in Delphi has noticably slowed down the compiler and increased binary sizes. To my dismay, compile times of 20 seconds up to 2 minutes have become not uncommon in Delphi.

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-08 Thread Sven Barth via fpc-devel
Am 07.05.2021 um 23:16 schrieb Ryan Joseph via fpc-devel: On May 7, 2021, at 2:52 PM, Sven Barth wrote: As said the main problem of reference counting on object instances, especially if enabled by default like the Delphi NextGen compiler did, will lead to problems in *existing* code and

Re: [fpc-devel] (ref types / circles) Re: Defer keyword

2021-05-07 Thread Sven Barth via fpc-devel
Ryan Joseph via fpc-devel schrieb am Fr., 7. Mai 2021, 05:58: > > > > On May 6, 2021, at 7:14 PM, Ryan Joseph wrote: > > > > This can be detected at compile and at least give a warning. "a" is a > member of TR and the element type of "a" is TR, then we're assigning TR to > said array. It's that

Re: [fpc-devel] Defer keyword

2021-05-07 Thread Sven Barth via fpc-devel
Michael Van Canneyt via fpc-devel schrieb am Fr., 7. Mai 2021, 08:14: > > > On Fri, 7 May 2021, Sven Barth via fpc-devel wrote: > > > > > In my opinion the better solution is to continue the road that Maciej > > started and to implement that "default field&

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Sven Barth via fpc-devel
Am 07.05.2021 um 00:32 schrieb Ryan Joseph via fpc-devel: On May 6, 2021, at 4:26 PM, J. Gareth Moreton via fpc-devel wrote: There is a performance penalty when using them, which one reason why the compiler sources don't use them. There's probably other reasons too. There might be some

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Sven Barth via fpc-devel
Am 07.05.2021 um 00:17 schrieb Ryan Joseph via fpc-devel: On May 6, 2021, at 4:05 PM, Sven Barth via fpc-devel wrote: Other than that, you're right and what Ryan is trying to do is definitely the intended purpose of try ... finally. Is there any runtime code involved with try..finally

Re: [fpc-devel] Defer keyword

2021-05-06 Thread Sven Barth via fpc-devel
J. Gareth Moreton via fpc-devel schrieb am Do., 6. Mai 2021, 20:03: > The rule with try...finally is that, outside of something completely > catastrophic that destroys the program flow, is that once you enter the > try part, the finally part is guaranteed to be executed no matter how > you leave

Re: [fpc-devel] Type helper bug

2021-05-05 Thread Sven Barth via fpc-devel
Zeljko Avramovic via fpc-devel schrieb am Mi., 5. Mai 2021, 12:42: > In example bellow, both record field ID.PGN and type helper for that > record field ID.PGN.PS point to the same memory location in a bitpacked > record not aligned to a byte. ID.PGN can be modified correctly. ID.PGN.PS > can

Re: [fpc-devel] Nested function closures

2021-04-27 Thread Sven Barth via fpc-devel
Am 27.04.2021 um 21:19 schrieb Ryan Joseph via fpc-devel: On Apr 27, 2021, at 12:10 PM, Sven Barth via fpc-devel wrote: So as Sven wrote, you would be duplicating effort, needlessly, since it has to work always... If the compiler can decide that the heap interface is not needed

Re: [fpc-devel] Nested function closures

2021-04-27 Thread Sven Barth via fpc-devel
Am 27.04.2021 um 17:58 schrieb Michael Van Canneyt via fpc-devel: On Tue, 27 Apr 2021, Ryan Joseph via fpc-devel wrote: Continued from our discussion at https://bugs.freepascal.org/view.php?id=24481. if the compiler devs will allow me as soon as this is finished I want to allow the

Re: [fpc-devel] Nested function closures

2021-04-27 Thread Sven Barth via fpc-devel
Am 27.04.2021 um 17:44 schrieb Ryan Joseph via fpc-devel: Continued from our discussion at https://bugs.freepascal.org/view.php?id=24481. if the compiler devs will allow me as soon as this is finished I want to allow the existing nested functions functionality to work with anonymous

Re: [fpc-devel] [fpc-pascal] How does TFPGMap key compare work?

2021-04-22 Thread Sven Barth via fpc-devel
Ryan Joseph via fpc-devel schrieb am Fr., 23. Apr. 2021, 00:53: > > > > On Apr 21, 2021, at 11:21 PM, Sven Barth > wrote: > > > > You need to use named types, though for operators this is less useful, > because the compiler will implicitly convert different ShortString types to > find a

Re: [fpc-devel] [fpc-pascal] How does TFPGMap key compare work?

2021-04-21 Thread Sven Barth via fpc-devel
Am 21.04.2021 um 20:05 schrieb Ryan Joseph via fpc-devel: On Apr 20, 2021, at 11:38 PM, Sven Barth wrote: All four string types provide built in > and < operators: On a side note how do you even make overloads (or type helpers for that matter) for short strings because String[10] isn't the

Re: [fpc-devel] Generic class comparison operators

2021-04-21 Thread Sven Barth via fpc-devel
Am 21.04.2021 um 15:44 schrieb Benito van der Zander via fpc-devel: Hi,  what about overloading operators for OBJECTs? They do not conflict with any default operators. I expected this to work, but it did not compile:   type generic TXQHashset = object //(specialize TXQBaseHashmap)...    

Re: [fpc-devel] Generic class comparison operators

2021-04-21 Thread Sven Barth via fpc-devel
Am 21.04.2021 um 16:54 schrieb Ryan Joseph via fpc-devel: On Apr 18, 2021, at 1:37 AM, Sven Barth wrote: It has been decided back when operator overloads were introduced that they do not replace existing, built in operators. This decision still stands. And we see no reason to change that.

Re: [fpc-devel] FreeBSD PowerPC64 Port

2021-04-18 Thread Sven Barth 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. You can orient yourself at the changes done to port FPC to

Re: [fpc-devel] Generic class comparison operators

2021-04-18 Thread Sven Barth via fpc-devel
Ryan Joseph via fpc-devel schrieb am So., 18. Apr. 2021, 02:18: > Since I'm working on generics right now can we finally, at the very least, > allow class operators for comparison operators? This is literally the only > way for a generic class to override the = operator (along with some others)

Re: [fpc-devel] Implicit function specialization precedence

2021-04-16 Thread Sven Barth via fpc-devel
Ryan Joseph via fpc-devel schrieb am Fr., 16. Apr. 2021, 00:38: > > > > On Apr 14, 2021, at 3:49 PM, Ryan Joseph wrote: > > > > It works but it thinks this array is array of const also so it's too > strict I believe. > > > > ['aaa', 'bbb']; > > About this, shouldn't we just be doing this? Any

Re: [fpc-devel] Implicit function specialization precedence

2021-04-14 Thread Sven Barth via fpc-devel
Am 14.04.2021 um 23:49 schrieb Ryan Joseph via fpc-devel: On Apr 14, 2021, at 2:33 PM, Sven Barth wrote: Had a bit of time to look at this. You can try the attached patch. You can then check for both ado_IsConstructor and ado_IsArrayOfConst to detect such a mixed array. It works but it

Re: [fpc-devel] Implicit function specialization precedence

2021-04-14 Thread Sven Barth via fpc-devel
Am 11.04.2021 um 23:38 schrieb Ryan Joseph via fpc-devel: On Apr 11, 2021, at 3:33 PM, Sven Barth wrote: Looking at it, it could be that there is a bug in tarrayconstructornode.pass_typecheck that hasn't really surfaced yet... I'll have to look at that first, but I don't know when I'll

Re: [fpc-devel] Implicit function specialization precedence

2021-04-11 Thread Sven Barth via fpc-devel
Am 11.04.2021 um 22:27 schrieb Ryan Joseph via fpc-devel: On Apr 10, 2021, at 9:47 AM, Ryan Joseph wrote: Just checked and pass_typecheck is called before overloading but ado_IsVariant is simply never set for that array. In tarraydef.GetTypeName you can see that "array of const" is

Re: [fpc-devel] Implicit function specialization precedence

2021-04-10 Thread Sven Barth via fpc-devel
Am 10.04.2021 um 10:38 schrieb Sven Barth: Am 10.04.2021 um 00:43 schrieb Ryan Joseph via fpc-devel: On Apr 9, 2021, at 4:31 PM, Sven Barth via fpc-devel wrote: You mean what you did for is_array_literal? A pure array constructor can be found with is_array_constructor, though it might

Re: [fpc-devel] Implicit function specialization precedence

2021-04-10 Thread Sven Barth via fpc-devel
Am 10.04.2021 um 00:43 schrieb Ryan Joseph via fpc-devel: On Apr 9, 2021, at 4:31 PM, Sven Barth via fpc-devel wrote: You mean what you did for is_array_literal? A pure array constructor can be found with is_array_constructor, though it might be better to use is_open_array, cause someone

Re: [fpc-devel] Implicit function specialization precedence

2021-04-09 Thread Sven Barth via fpc-devel
Am 09.04.2021 um 23:52 schrieb Ryan Joseph via fpc-devel: On Apr 9, 2021, at 3:08 PM, Sven Barth wrote: Possibly, yes... You could provide the various utility functions in a separate patch. Well I'm going to use them for this patch so they would all be batched together. Any idea about the

Re: [fpc-devel] Implicit function specialization precedence

2021-04-09 Thread Sven Barth via fpc-devel
Am 09.04.2021 um 18:12 schrieb Ryan Joseph via fpc-devel: On Apr 8, 2021, at 11:37 PM, Sven Barth via fpc-devel wrote: That is because before the introduction of type helpers such functions weren't really needed. Other mechanisms caught such constants, but for both type helpers

Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Sven Barth via fpc-devel
Am 09.04.2021 um 04:20 schrieb Ryan Joseph via fpc-devel: On Apr 8, 2021, at 3:53 PM, Sven Barth wrote: 1. you should not blindly assume that the def is a stringdef if it's not an arraydef; at least use an internalerror to protect against problems here 2. if it's really a stringdef and the

Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Sven Barth via fpc-devel
Am 08.04.2021 um 19:28 schrieb Ryan Joseph via fpc-devel: On Apr 7, 2021, at 1:56 PM, Ryan Joseph wrote: Ok, so with $H+ constant strings will be specialized as AnsiStrings. And there is another unicode string mode I should do a similar thing with? Also if you happen to know where I can

Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Sven Barth via fpc-devel
Am 07.04.2021 um 23:21 schrieb Ryan Joseph via fpc-devel: With the requested changes I believe some precedence rules have changed. These both should be "Can't determine which overloaded function to call" errors or the non-generic should take precedence because the functions are ambiguous (by

Re: [fpc-devel] Implicit function specialization precedence

2021-04-07 Thread Sven Barth via fpc-devel
Am 07.04.2021 um 18:16 schrieb Ryan Joseph via fpc-devel: On Apr 6, 2021, at 11:34 PM, Sven Barth wrote: In the second case the compiler will have the non-generic Test(String) due to the implicit operator as well as Test(LongInt) due to the implicit specialization. Here it will pick the

Re: [fpc-devel] Implicit function specialization precedence

2021-04-06 Thread Sven Barth via fpc-devel
Am 06.04.2021 um 23:11 schrieb Ryan Joseph via fpc-devel: On Apr 6, 2021, at 12:57 PM, Sven Barth wrote: In the example you posted below, I agree with you, but that is not what I said. Look at my example again: Also could you please verify that $H+ isn't causing problems? The string

Re: [fpc-devel] Implicit function specialization precedence

2021-04-06 Thread Sven Barth via fpc-devel
Am 06.04.2021 um 22:47 schrieb Ryan Joseph via fpc-devel: On Apr 6, 2021, at 12:57 PM, Sven Barth wrote: In this specific case the two functions also are *not* ambigous, because for the non-generic Test the parameter requires an implicit conversion, but the implicit specialization does

  1   2   3   4   5   6   7   >