Re: [fpc-devel] TThread.RemoveQueuedEvents

Am 26.09.2020 um 14:19 schrieb Mattias Gaertner via fpc-devel: On Sat, 26 Sep 2020 14:05:21 +0200 Martin Frb via fpc-devel wrote: On 26/09/2020 13:58, Pascal Riekenberg wrote: Hi Martin, there is a free Community Edition. Ok, but maybe someone who already has it installed, can copy and

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

Travis Siegel via fpc-devel schrieb am Mo., 28. Sep. 2020, 10:01: > But, in any case, if there's a way to get 64-bit versions on windows, I'd > like to know how. > Easiest: install a 64-bit Lazarus, it contains a 64-bit FPC. Other than that: download the source for your compiler version and

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

Ben Grasset via fpc-devel schrieb am So., 27. Sep. 2020, 07:50: > That last quote is absolute BS, to be very frank. There is no reason > whatsoever not to use a natively-64-bit copy of FPC if running a > natively-64-bit copy of Windows, and there hasn't been for well over half a > decade at this

Re: [fpc-devel] Unknown compilerproc in r 46894

Am 19.09.2020 um 14:11 schrieb Ryan Joseph via fpc-devel: On Sep 19, 2020, at 5:43 PM, Jonas Maebe via fpc-devel wrote: It will work if you start your build with FPC 3.2.0 instead of 3.0.4. yes, that worked. thanks. 3.0.4 is officially not possible to use for bootstrapping I guess.

Re: [fpc-devel] Feature request/discussion - SetLengthNoInit

Benito van der Zander via fpc-devel schrieb am Mi., 16. Sep. 2020, 15:30: > > Hi, > > > I'm against adding support for this. Dynamic arrays have guaranteed > behavior. If users find that this behavior is not appropriate for their use > case then they should not use them (or as you already

Re: [fpc-devel] Feature request/discussion - SetLengthNoInit

J. Gareth Moreton via fpc-devel schrieb am Mi., 16. Sep. 2020, 16:10: > I did wonder if it was possible to use an object of some kind or, I dare > say, some evil low-level manipulation of its internal structure wrapped > into a convenient function that, say, calls ReallocMem on the internal >

Re: [fpc-devel] Feature request/discussion - SetLengthNoInit

J. Gareth Moreton via fpc-devel schrieb am Mo., 14. Sep. 2020, 19:00: > With all this in mind, would there be support for an intrinsic such as > "SetLengthNoInit" or "SetLengthNoClear" or some similar name that has > all the benefits of SetLength (especially the reference counting) but > doesn't

Re: [fpc-devel] Planning to experiment with FPC extentions

Boian Mitov via fpc-devel schrieb am Mi., 26. Aug. 2020, 03:02: > Hello everyone, > > I have been planning for long time to try to add support for advanced RTTI > to FPC, but never had the chance to work on it. > I don’t even know how to start. Is there any information on how to setup > for

Re: [fpc-devel] TThread.Terminate;

Am 22.08.2020 um 18:45 schrieb Jonas Maebe via fpc-devel: On 22/08/2020 17:39, Martin Frb via fpc-devel wrote: I guess the "Terminate" field is actually about cache coherency. Yes, but as mentioned earlier it's in general completely useless to force the overhead of cache coherency for it. By

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

Am 22.08.2020 um 07:06 schrieb Pascal Riekenberg via fpc-devel: Kirinn via fpc-devel hat am 22. August 2020 um 03:50 geschrieben: For set/reset counting we'd need a semaphore instead of an RTL event, but I don't think we have an actively supported semaphore implementation at this time. I can

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

Am 22.08.2020 um 02:44 schrieb Martin via fpc-devel: I am tracing a race condition in lazCollections TLazThreadedQueue on win-64 What is supposed to happen in the following case: 2 or more threads are waiting on the some event   RTLeventWaitFor(UniqueEvent) 1 thread sets it  

Re: [fpc-devel] ARM/AARCH64 work

J. Gareth Moreton schrieb am Fr., 7. Aug. 2020, 01:22: > Okay, got it to compile. I had to make a cfg file with absolute paths > though that I Have to > explicitly reference, since the trunk build puts ppca64 into > /usr/local/fpc/3.3.1 and I'm not sure > where it looks for fpc.cfg normally.

Re: [fpc-devel] ARM/AARCH64 work

J. Gareth Moreton schrieb am Do., 6. Aug. 2020, 22:36: > Hi guys, can you confirm that Lazarus compiles on aarch64? When I try > under aarch64-linux (with > fresh SVN checkouts), it fails with the error message: > > Fatal: (10022) Can't find unit db used by fcllaz > Can you compile a simple

Re: [fpc-devel] ARM/AARCH64 work

Marc Weustink via fpc-devel schrieb am Do., 6. Aug. 2020, 09:13: > > > On 5-8-2020 23:44, Sven Barth via fpc-devel wrote: > > Am 05.08.2020 um 18:33 schrieb J. Gareth Moreton: > >> P.S. While I haven't been asked to improve aarch64-linux specifically, > >

Re: [fpc-devel] ARM/AARCH64 work

Am 05.08.2020 um 22:44 schrieb J. Gareth Moreton: I can't promise anything just yet, but I'll see what I can do. At the moment I'm still learning to configure anything. I've had apps crash from out of memory errors and the CPU get throttled due to overheating while trying to play a YouTube

Re: [fpc-devel] ARM/AARCH64 work

Am 05.08.2020 um 18:33 schrieb J. Gareth Moreton: P.S. While I haven't been asked to improve aarch64-linux specifically, if I'm understanding things correctly, there should be very few differences with the actual target platform in regards to calling conventions, for example. Correct, the most

Re: [fpc-devel] Revision 45973 breaks build for arm-embedded target on my Mac

Am 01.08.2020 um 13:36 schrieb Michael Ring via fpc-devel: Null problemo, thanks for the update! Should be fixed in r45981. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Revision 45973 breaks build for arm-embedded target on my Mac

Michael Ring via fpc-devel schrieb am Sa., 1. Aug. 2020, 13:26: > Revision 45972 builds fine, all Revisions since 45973 create this error > on my Mac. I checked with armv6m, armv7m and armv7em subarchs: > It's already on my list, though I can't fix it *right now* as I have an appointment. For

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

J. Gareth Moreton schrieb am Sa., 25. Juli 2020, 22:24: > Since 3.2.0 has already had a public release, should the version number > be incremented to 3.2.1 or some such? > The version of the fixes branch already *is* 3.2.1 since 20th June (

Re: [fpc-devel] Binary size discrepancy with -a

J. Gareth Moreton schrieb am So., 19. Juli 2020, 11:20: > Ah, of course! It's still a remarkable difference though and I wonder if > the internal assembler could use an update in that case. > Feel free to find out where the difference comes from. ;) Regards, Sven >

Re: [fpc-devel] Binary size discrepancy with -a

J. Gareth Moreton schrieb am So., 19. Juli 2020, 05:09: > Hi everyone, > > I've noticed something a bit weird with the Free Pascal Compiler when > you use the the -a option to dump the compiled assembly files... the > resultant binaries are sometimes smaller. I recently tried it with > Lazarus

Re: [fpc-devel] Fwd: Re: An optimization suggestion for FPC

J. Gareth Moreton schrieb am Mo., 13. Juli 2020, 12:23: > I haven't been able to test it as rigorously as I would have liked. I'm > having some difficulty compiling projects under Lazarus with the trunk > since it tries to recompile windows.ppu due to a checksum mismatch, and > immediately

Re: [fpc-devel] just for information

Am 12.07.2020 um 09:37 schrieb Samuel Herzog via fpc-devel: Hello List-Members, first of all thank you all for the FPC 3.2 release! I am the maintainer of sourceforge.net/projects/scimarkfordelphi/ Scimark for Delphi

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

Ryan Joseph via fpc-devel schrieb am Mo., 6. Juli 2020, 19:04: > > > > On Jul 4, 2020, at 8:10 PM, Marco van de Voort < > f...@pascalprogramming.org> wrote: > > > > But the syntax will be CARD(variable), and there are some minor > things wrong with it: (anyone?) > > I'm waiting on my patch for

Re: [fpc-devel] FPC and Z80

Am 23.06.2020 um 18:59 schrieb popolon...@popolony2k.com.br: Thanks a lot. Everything is working fine. I compiled my first FPC code (simple hello world)  to MSX-DOS2 and is working fine. Good to know. :) The only thing I realized, is something someone here wrote before, that is the size of

Re: [fpc-devel] FPC and Z80

Christo Crause schrieb am Di., 23. Juni 2020, 16:37: > On Tue, Jun 23, 2020 at 3:56 PM wrote: > >> Hi FPC team. >> >> I'm trying to compile a FPC 3.2 with support to Z80/MSXDOS, for linux and >> almost everything seems to be compiling fine, because the compiler was >> generated but RTL was not.

Re: [fpc-devel] FPC and Z80

schrieb am Di., 23. Juni 2020, 15:56: > Hi FPC team. > > I'm trying to compile a FPC 3.2 with support to Z80/MSXDOS, for linux and > almost everything seems to be compiling fine, because the compiler was > generated but RTL was not. > > I'm using the same build script of zxspectrum (I just

Re: [fpc-devel] Generic method works on Linux, not on Windows?

Am 30.05.2020 um 14:28 schrieb Sven Barth: Am 30.05.2020 um 12:33 schrieb Yuriy Sydorov: On 29.05.2020 22:36, Sven Barth via fpc-devel wrote: Am 27.05.2020 um 00:41 schrieb Yuriy Sydorov: On 27.05.2020 1:01, Joost van der Sluis wrote: Op 26-05-2020 om 23:36 schreef Yuriy Sydorov: Does

Re: [fpc-devel] Allow object type property getter to expose a field as one of its base/parent types (patch included)

Am 04.06.2020 um 03:45 schrieb Kostas Michalopoulos via fpc-devel: Hello, I'd like to add a small feature for property getters to allow themselves be exposed as a base type of the real field. Example: === program ExposeDerivedAsBase; {$mode objfpc} type TBase = class end; TDerived =

Re: [fpc-devel] FPC and Z80

PopolonY2K schrieb am Mi., 10. Juni 2020, 00:38: > Thank you. > > My library is very complete, 100% MSXBIOS, MSXDOS and MSXDOS2, Memory > mapper and several others implementations ready, but they are working just > with TP3. > > Features like Inline code are provided by FPC by using Asm/EndAsm.

Re: [fpc-devel] FPC and Z80

PopolonY2K schrieb am Di., 9. Juni 2020, 16:03: > Thanks. > > I'll start porting all Turbo Pascal 3 library compatible, to FPC using > units. > Great! If you find any problems, please don't hesitate to report them either here or on the bugtracker at bugs.freepascal.org :) And if you have any

Re: [fpc-devel] FPC and Z80

Am 16.04.2020 um 11:04 schrieb Guillermo: Thanks Swen. I see last commit was 2 days ago so it is active. I would like to know who is responsible to speak to him. May be I can help with the MSX target, but I need gidance about the internals of the compiler (I tried but it is beyond my

Re: [fpc-devel] Generic method works on Linux, not on Windows?

Am 30.05.2020 um 12:33 schrieb Yuriy Sydorov: On 29.05.2020 22:36, Sven Barth via fpc-devel wrote: Am 27.05.2020 um 00:41 schrieb Yuriy Sydorov: On 27.05.2020 1:01, Joost van der Sluis wrote: Op 26-05-2020 om 23:36 schreef Yuriy Sydorov: Does it happen with the fpc trunk? If yes, what

Re: [fpc-devel] Generic method works on Linux, not on Windows?

Am 27.05.2020 um 00:41 schrieb Yuriy Sydorov: On 27.05.2020 1:01, Joost van der Sluis wrote: Op 26-05-2020 om 23:36 schreef Yuriy Sydorov: Does it happen with the fpc trunk? If yes, what revision do you use? It looks like an issue with my initial implementation of the $parentfp parameter

Re: [fpc-devel] Different versions of register name search algorithms used

Am 20.05.2020 um 18:09 schrieb Christo Crause via fpc-devel: While trying to understand bug 0037121I noticed that the predominant search algorithm used for finding register names is a binary search without a match check.  My understanding of this algorithm is that it will always run the

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

NetSpirit via fpc-devel schrieb am Di., 19. Mai 2020, 11:44: > > Please report as a bug. > > > > > > Regards, > > Sven > > > > I don't have an account in bug tracker. I post here to get confirmation > and opinion from other members. > In hope that one, who can create bug reports, will do this. >

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

NetSpirit via fpc-devel schrieb am Di., 19. Mai 2020, 10:05: > > if anyone wants to assign me one of the new bugs to fix that have been > > raised since the RC was released, I'll be happy to take a look. > > > Gareth aka. Kit > > > Not special for this RC but some bugs: > > === > 1)

Re: [fpc-devel] r45217 breaks Lazarus compile

Marc Weustink via fpc-devel schrieb am Di., 5. Mai 2020, 11:21: > > Also debugging *is* the *only* > > purpose of this. Not to mention that this is a write only functionality. > > There is no way to retrieve the thread's name and it's also not stored > > anywhere on the Pascal side. > > Not

Re: [fpc-devel] r45217 breaks Lazarus compile

Michael Van Canneyt schrieb am Di., 5. Mai 2020, 11:33: > > > On Tue, 5 May 2020, Marco van de Voort wrote: > > > > > Op 2020-05-05 om 11:08 schreef Sven Barth via fpc-devel: > >> > >> ForDebugging is just one of the purposes, and TThread.NameThread

Re: [fpc-devel] r45217 breaks Lazarus compile

Marc Weustink via fpc-devel schrieb am Di., 5. Mai 2020, 09:27: > Sven Barth via fpc-devel wrote: > > > > TThread.NameThreadForDebugging is implemented for Windows, Linux and > > Android since the weekend. > > Just curious, why is NameThreadForDebugging used inste

Re: [fpc-devel] r45217 breaks Lazarus compile

C Western schrieb am Mo., 4. Mai 2020, 09:59: > > > I have added protections against empty strings in r45237, though I > > would be quite curious what already called > > TThread.NameThreadForDebugging considering it was implemented only > > recently... > > In fact I had added a call to

Re: [fpc-devel] r45217 breaks Lazarus compile

Am 03.05.2020 um 22:51 schrieb C Western: On 03/05/2020 20:59, C Western wrote: On 02/05/2020 10:36, C Western wrote: Compiling Lazarus trunk with the latest fpc: components/ideintf/propedits.pp(6019,28) Fatal: Internal error 200709171 Colin Seems now to be fixed in a recent update.

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

schrieb am Fr., 1. Mai 2020, 21:12: > On 5/1/20 10:50 AM, Bart via fpc-devel wrote: > > On Fri, May 1, 2020 at 3:59 PM Sven Barth > wrote: > > > >> Bart had only replied to me, thus I fully quote his mail here. > > > > There is something fishy goin

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

Bart schrieb am Fr., 1. Mai 2020, 16:50: > On Fri, May 1, 2020 at 3:59 PM Sven Barth > wrote: > > > Bart had only replied to me, thus I fully quote his mail here. > > There is something fishy going on with this ML. > Whenever I click on reply in this list, the reply

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

Bart had only replied to me, thus I fully quote his mail here. Am 01.05.2020 um 10:29 schrieb Bart: On Thu, Apr 30, 2020 at 11:43 PM Sven Barth wrote: Between 3.2.0 and 3.3.1 an additional PPU entry was introduced that carries an additional PPU version (the original version field is 1 Byte

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

Am 30.04.2020 um 22:55 schrieb Bart via fpc-devel: On Thu, Apr 30, 2020 at 4:45 PM Michael Van Canneyt wrote: Sorry, my reply to Michael went to his private mail, not to the lis, so I copy it here: It does try to load the one in fpc.cfg, but it is invalid: No it does not. Again:

Re: [fpc-devel] Pure function development

J. Gareth Moreton schrieb am Do., 30. Apr. 2020, 17:07: > Currently I'm not using the constant propagation code for the pure > function feature, but after some refactoring down the line, hopefully > they can be made to use the same code and hence improve both features > drastically. Note that

Re: [fpc-devel] Pure function development

Am 29.04.2020 um 23:59 schrieb J. Gareth Moreton: I suppose node emulation would be equivalent to constant propagation.  I sense we might need to refactor things afterwards so the same code can be reused for both purposes.  My current design for the emulation would introduce a new virtual

Re: [fpc-devel] Pure function development

Am 29.04.2020 um 22:51 schrieb Jonas Maebe: On 29/04/2020 22:43, J. Gareth Moreton wrote: So are you officially rejecting pure functions and my future work on them in this form? I'm just trying to say that there is already a (primitive) framework for propagating constant values through

Re: [fpc-devel] Pure function development

Am 29.04.2020 um 00:31 schrieb J. Gareth Moreton: Hi everyone, I'm having a serious bash at developing pure functions for FPC now, specifically 'node emulation' so it can step through a pure function and compute output values.  One of the small problems I'm trying to solve is keeping track

Re: [fpc-devel] FPC and Z80

Florian Klaempfl schrieb am Mo., 27. Apr. 2020, 18:28: > Am 27.04.2020 um 17:52 schrieb Karoly Balogh (Charlie/SGR): > > Hi, > > > > On Mon, 27 Apr 2020, Sven Barth via fpc-devel wrote: > > > >>> Well, I'm surprised and impressed you got it to wo

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

Ryan Joseph via fpc-devel schrieb am Mo., 27. Apr. 2020, 18:28: > I think constants in generics may be the only way to create dynamically > sized types at compile time (via static arrays). That seems like a really > narrow usage but it opens a lot of doors most of us have probably never >

Re: [fpc-devel] FPC and Z80

Michael Van Canneyt schrieb am Mo., 27. Apr. 2020, 15:40: > > > On Mon, 27 Apr 2020, nickysn--- via fpc-devel wrote: > > > Last night, I got the full system unit to compile, including console > > output, so now you can use standard write/writeln. Unfortunately if you > > include both read/readln

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

Am 26.04.2020 um 23:42 schrieb Benito van der Zander: Hi Sven, It's not that simple. In principle you're right that the compiler could try to merge more implementations, but this does not depend on the declaration of the generic, but the use of the parameter types. I mostly use generics

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

Am 26.04.2020 um 14:01 schrieb Benito van der Zander: Hi, perhaps it could be used to merge specializations (if fpc cannot do that on its own): Like when you have a hashmap THashMap, and need three specializations: THashMap THashMap THashMap It is basically three times the same

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

Am 26.04.2020 um 09:38 schrieb Michael Van Canneyt: On Sun, 26 Apr 2020, Ryan Joseph via fpc-devel wrote: On Apr 26, 2020, at 5:13 AM, Sven Barth via fpc-devel wrote: The Free Pascal team is happy to announce the addition of a new language feature: constant parameters for generics

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

The Free Pascal team is happy to announce the addition of a new language feature: constant parameters for generics. This allows to declare generic types or routines that aside from type parameters can also take constant parameters that can be used inside the generic as if one would use

Re: [fpc-devel] Nasty generics-bug, already known?

Am 24.04.2020 um 22:27 schrieb Joost van der Sluis: Hi all, Sven, I have a very nasty bug related to generics. Suppose that I have a unit with a generic-class in it. Nothing more. This unit is in a package. Now I also have a unit which is part of an application. Within this unit I

Re: [fpc-devel] FPC now supports Windows 33-bit

Am 22.04.2020 um 22:21 schrieb Bart via fpc-devel: Hi, Please don't feel offended, but this typo just made me smile: (And a smile is what we need in these harsh times) Revision 44996 "Moved the common interface part of the win33 and win64 System units to the syswinh.inc include file." Lol...

Re: [fpc-devel] Refactoring tobjectdef.vmt_def

Am 21.04.2020 um 10:57 schrieb bla...@blaise.ru: I have questions/suggestions WRT Jonas' SVN r42342: https://github.com/graemeg/freepascal/commit/40d31e34116efffa239b6dc94373fcfccedfa646 Yay, a life sign! :D Regards, Sven ___ fpc-devel maillist -

Re: [fpc-devel] State of SSE/AVX intrinsics

denisgolovan schrieb am Di., 21. Apr. 2020, 14:58: > > I think Gareth meant the address of V instead (Pointer(@V)). > > > > Regards, > > Sven > > Hm. I have no idea why anyone would take pointer to pointer :) > Because they might have forgotten that dynamic arrays behave different from static

Re: [fpc-devel] State of SSE/AVX intrinsics

denisgolovan via fpc-devel schrieb am Di., 21. Apr. 2020, 13:32: > > > > One thing to be slightly aware of with > > dynamic pointers and alignment. For V: atray > > of Integer etc, make sure you check the > > alignment of V[0], not V. V points to an > > internal structure that is largely opaque,

[fpc-devel] New Target Announcement: Windows on ARM64

Hello together! I'm happy to announce initial support for the Windows on ARM64 target, aka aarch64-win64. Simple programs work already and the compiler is at least able to display its help message (when trying to compiler something it silently crashes, I've not yet found out why that is the

Re: [fpc-devel] FPC and Z80

Am 13.04.2020 um 13:08 schrieb Guillermo: Hi Pascaloids, I've read in the web forums[1] that FPC may include Zylog Z80 as target, specifically Sinclair's micro computers, but looking at the SVN[2] I don't see any Z80 reference. It's currently in development in a branch:

Re: [fpc-devel] Rules about record types and internal storage

J. Gareth Moreton schrieb am Do., 2. Apr. 2020, 22:33: > Hi Jonas, > > I brought that up because Florian once asked about just doing everything > as vectorcall on Win64 because the calling convention, by and large, is > a compatible extension to its default one. I think issues of >

Re: [fpc-devel] Rules about record types and internal storage

Sven Barth schrieb am Do., 2. Apr. 2020, 17:10: > P.S. Of course you can force it by forcing the vector to be an m128 type >> and specifying vectorcall for x86_64-win64, but not everyone will know >> to do that and it gets unwieldly rather quickly. Speaking of >> vectorcall

Re: [fpc-devel] Rules about record types and internal storage

J. Gareth Moreton schrieb am Do., 2. Apr. 2020, 15:25: > For standard record types (no "packed" modifier or compiler directives > or anything), I'm wondering how many liberties that the compiler is > allowed to take in storing its data. Take the following example (from > raybench.pas over here:

Re: [fpc-devel] Error building xtensa rtl

Christo Crause schrieb am Di., 31. März 2020, 19:45: > On Tue, Mar 31, 2020 at 7:39 AM Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > >> Am 30.03.2020 um 22:07 schrieb Christo Crause via fpc-devel: >> >> I've noticed GCC uses the SLLI +

Re: [fpc-devel] Error building xtensa rtl

Am 30.03.2020 um 22:07 schrieb Christo Crause via fpc-devel: On Sun, Mar 29, 2020 at 11:00 PM Florian Klämpfl mailto:flor...@freepascal.org>> wrote: Am 29.03.20 um 22:46 schrieb Christo Crause via fpc-devel: > It seems that a different instruction sequence should be used for sign

Re: [fpc-devel] XTensa support question

Christo Crause via fpc-devel schrieb am Mo., 23. März 2020, 18:18: > I've noticed some Xtensa support appear in trunk. This is exiting news > for me. Are there some plans/ideas in terms of linking to existing > frameworks such as Espressif's SDKs or Ultibo? > Once FPC support for the

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Sven Barth schrieb am Sa., 14. Dez. 2019, 18:18: > Am 09.12.2019 um 01:03 schrieb bla...@blaise.ru: > > > > @Jonas: Has the team decided on the amended syntax for C-block > > references? I am ready to start implementing whichever. > > > In r43684 t

Re: [fpc-devel] Public modifier: brackets or not?

Bart via fpc-devel schrieb am So., 23. Feb. 2020, 16:35: > However, this will compile also: > > Function Second : Real; [Public name ’second’]; > begin > Second := 1; > end; > > So, what is the correct syntax? > Both are correct. The brackets allow a comma separated list of directives.

Re: [fpc-devel] reference/pointer to class function/constructor ?

Harald Houppermans via fpc-devel schrieb am Fr., 21. Feb. 2020, 12:37: > *** Shorter version / less explanation ***: > (Alternative shorter version): > > I want/have the need to do the following, I want one unit as follows: > > UnitVersion: > > type > TVersion = > ( > v1, > v2, >

Re: [fpc-devel] Finally fixed that MOVZX/SX optimisation!

Am 19.02.2020 um 20:37 schrieb Florian Klämpfl: Am 19.02.20 um 11:23 schrieb Sven Barth via fpc-devel: J. Gareth Moreton <mailto:gar...@moreton-family.com>> schrieb am Mi., 19. Feb. 2020, 01:40:     Ah, I understand, thank you.     I chose those two tests in particular because t

Re: [fpc-devel] Finally fixed that MOVZX/SX optimisation!

J. Gareth Moreton schrieb am Mi., 19. Feb. 2020, 01:40: > Ah, I understand, thank you. > > I chose those two tests in particular because the design with multiple > typecasts opens it up to a lot of peephole optimisations. > The nightly testsuite is run multiple times with different settings, so

Re: [fpc-devel] Running individual tests

J. Gareth Moreton schrieb am Mi., 12. Feb. 2020, 23:48: > Hi everyone, > > This might be a bit of a silly question, but is there a way to run > individual tests from the test suite using the "make" command? I ask > because Florian has pointed out some failures on one of my patches and I > rather

Re: [fpc-devel] Linux Binary - Socket Output affected by SystemCtl, HELP!

Ozz Nixon via fpc-devel schrieb am Mi., 29. Jan. 2020, 16:51: > PS. Worsecase, I can scrap 2.6.4 for 3.0.x - just been waiting for a > stable LLVM build for all 3 OSes I support. > Then you're in for long wait as the LLVM backend is fully supported only on trunk (at least for macOS and Linux on

Re: [fpc-devel] Android 64-bit

Am 25.01.2020 um 17:17 schrieb Adriaan van Os: Florian Klämpfl wrote: Am 25.01.20 um 14:40 schrieb Sven Barth via fpc-devel: mips64 are supported with 3.2 and newer. FPC has no mips64 support yet :( As far as I know, 32-bit and 64-bit MPIS support was removed in the Android Native

Re: [fpc-devel] Android 64-bit

Florian Klämpfl schrieb am Sa., 25. Jan. 2020, 15:07: > Am 25.01.20 um 14:40 schrieb Sven Barth via fpc-devel: > > mips64 > > are supported with 3.2 > > and newer. > > FPC has no mips64 support yet :( > Right... -.- Then the mips64 folder in the Android folder

Re: [fpc-devel] Android 64-bit

Adriaan van Os schrieb am Sa., 25. Jan. 2020, 11:25: > Any news on the 64-bit compiler for Android ? What is the current status ? > As far as I am aware x86_64, aarch64 and mips64 are supported with 3.2 and newer. Regards, Sven > ___ fpc-devel

Re: [fpc-devel] The new XMM intrinsics

Am 18.01.2020 um 18:52 schrieb J. Gareth Moreton: I think more than anything I would like to see a degree of "ease of use" for the SIMD intrinsics, since modifying __m128 data in C/C++ is not that straightforward.  Just as a straightforward example, what might be the best way to ensure these

Re: [fpc-devel] The new XMM intrinsics

Am 18.01.2020 um 13:18 schrieb Florian Klämpfl: Am 18.01.20 um 12:53 schrieb Sven Barth via fpc-devel: Am 18.01.2020 um 12:46 schrieb Florian Klämpfl: Am 16.01.20 um 23:22 schrieb J. Gareth Moreton: Hey everyone, Maybe I'm being a bit pedantic with this, but must we abide by C/C++ standards

Re: [fpc-devel] The new XMM intrinsics

Am 18.01.2020 um 12:46 schrieb Florian Klämpfl: Am 16.01.20 um 23:22 schrieb J. Gareth Moreton: Hey everyone, Maybe I'm being a bit pedantic with this, but must we abide by C/C++ standards and go by the name __m128 etc. for the 128-bit data type? They can be added additionally. After some

Re: [fpc-devel] The new XMM intrinsics

Am 16.01.2020 um 23:22 schrieb J. Gareth Moreton: Hey everyone, Maybe I'm being a bit pedantic with this, but must we abide by C/C++ standards and go by the name __m128 etc. for the 128-bit data type?  Being as how Pascal tended to go for more readable and BASIC-inspired names like Integer

Re: [fpc-devel] SEH-based exceptions enabled on win32

J. Gareth Moreton schrieb am Fr., 10. Jan. 2020, 01:20: > Has code generation changed as a result? I recall i386 making heavy use > of push and pop within routines rather than pre-reserving the stack in > the prologue - this is a big no-no for SEH if I recall. > That might be due to the stack

Re: [fpc-devel] A more fundamental problem Re: i36507

J. Gareth Moreton schrieb am Fr., 3. Jan. 2020, 10:45: > Hi everyone, > > So I reported this morning that Lazarus no longer builds as of r43826. > Ondrej was quick to update the Lazarus sources to allow it to build > again and marking the issue as fixed, but the underlying regression in > the

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

Bart via fpc-devel schrieb am Fr., 3. Jan. 2020, 02:26: > On Thu, Jan 2, 2020 at 9:42 PM Ondrej Pokorny wrote: > > > It should be fixed with r43846. > Yes, thanks. > > > You may need to delete fpmake.exe and > > fpmake.o to make sure they are recompiled. > > Yes, it failed before that. > Good

Re: [fpc-devel] Proposal to change GetNextInstructionUsingReg

J. Gareth Moreton schrieb am So., 22. Dez. 2019, 19:18: > - Add a 4th parameter named "IgnoreConditionalJumps" with a default > value of False (so existing code doesn't break). Setting this to True > will allow the method to look past conditional jumps for instructions > that use the specified

Re: [fpc-devel] Assembler issue on bootstrapper

J. Gareth Moreton schrieb am So., 22. Dez. 2019, 01:15: > Aah, thanks Sven. Useful information. I see that FPC 3.2.0 only has a > couple of issues left on the roadmap. I hope 3.3.1 won't be too soon > after that, since that is when all my optimisation improvements start to > appear! > The

Re: [fpc-devel] Assembler issue on bootstrapper

Am 21.12.2019 um 17:45 schrieb J. Gareth Moreton: Hi everyone, I'm not sure if this counts as a bug or not, or if it is, if it's worth fixing.  When I attempt to bootstrap the compiler with OPT="-a" to dump the assembler files (I have my reasons!), it fails when building the fcl-pdf package

Re: [fpc-devel] inline... and philosophy

Am 16.12.2019 um 23:08 schrieb Marco van de Voort: Op 2019-11-21 om 22:56 schreef Sven Barth via fpc-devel: In the meantime I've managed to fix the dynamic package support that had experienced a bit of bit rot in the last years. Though I've currently only tested Win32 and Win64 (x86_64-linux

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 09.12.2019 um 01:03 schrieb bla...@blaise.ru: @Jonas: Has the team decided on the amended syntax for C-block references? I am ready to start implementing whichever. In r43684 the syntax was now adjusted, so that an additional "cblock" directive is required (in addition to the calling

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 12.12.2019 um 23:24 schrieb Ryan Joseph via fpc-devel: On Dec 12, 2019, at 11:13 AM, Martin Frb wrote: I brought an example, where actually the "drop [] for last param" would break code. Therefore it no longer matters if it is or is not against good design. Dropping the [], (in the new

Re: [fpc-devel] open array calling [[was: Re: C-block reference syntax (blocker for 3.2)]]

Am 12.12.2019 um 17:23 schrieb Michael Van Canneyt: On Thu, 12 Dec 2019, Martin Frb wrote: On 12/12/2019 17:14, Michael Van Canneyt wrote: On Thu, 12 Dec 2019, Sven Barth via fpc-devel wrote: For array of const it is not allowed, but any other open array parameter allows it. Really

Re: [fpc-devel] open array calling [[was: Re: C-block reference syntax (blocker for 3.2)]]

Am 12.12.2019 um 17:20 schrieb Martin Frb: On 12/12/2019 17:14, Michael Van Canneyt wrote: On Thu, 12 Dec 2019, Sven Barth via fpc-devel wrote: For array of const it is not allowed, but any other open array parameter allows it. Really, are you sure ? Since when is this allowed ? It works

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Michael Van Canneyt schrieb am Do., 12. Dez. 2019, 15:34: > > It was already mentioned, that the [] can be dropped if the array has > > *exactly one* element. > > Not sure what you mean here, but even if there is only 1 argument, today > the [] cannot be dropped: > > home:~> cat tf.pp > program

Re: [fpc-devel] Object/Pointer Swap Intrinsic

Am 12.12.2019 um 00:34 schrieb J. Gareth Moreton: That's true.  Given I specialise in optimisation, I've started to venture towards the node level to see where improvements can be made. One question I do have in that regard... are platform-specific nodes allowed? What I mean is, for example,

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 11.12.2019 um 23:40 schrieb Ryan Joseph via fpc-devel: On Dec 11, 2019, at 4:16 PM, Michael Van Canneyt wrote: It does gain something: it tells you it is NOT a varargs, but an array of const, which is a different beast altogether. But it's a syntax equivalent for "a variable amount of

Re: [fpc-devel] Refactoring TVMTBuilder

Am 05.12.2019 um 13:48 schrieb bla...@blaise.ru: 1) Currently, the following snippet vmtbuilder:=TVMTBuilder.Create(...); vmtbuilder.generate_vmt; vmtbuilder.free; is present @ types_dec :objectdef generate_specialization_phase2 :objectdef jvm_maybe_create_enum_class    

Re: [fpc-devel] C-block reference syntax (blocker for 3.2)

Am 09.12.2019 um 01:03 schrieb bla...@blaise.ru: On 08.12.2019 22:30, Sven Barth wrote: there is no official way to access such parameters 1) At the time of providing that answer on Stack Overflow, Barry Kelly worked as a DCC developer. While it is not truly official, it is pretty close

<    1   2   3   4   5   6   7   8   9   10   >