Re: [fpc-devel] New feature announcement: constant parameters for generics
> 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. Excellent! Thanks for getting this merged. It was a long battle but it's finally over. ;) Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Windows Console App
Anyone ever experience making a console app (cross-platform), but, on windows when the app finishes, it appears to have put an uppercase C or D in the keyboard buffer, so the Prompt now has C:\>D ??? Every time I run my app, be it show help screen and end, or actually execute - when it finishes I end up with a letter sitting at the prompt. (A few months ago, I was having a problem, and it was related to compiling all of the methods with cdecl. That build would leave a stray "C" at the start of the prompt upon exiting. Now, I ran into a new problem where I needed to recompile with -FcUTF8 to track down which units it thought were having a UTF-8 mismatch... it was showing the wrong unit until I used the -FcUTF8 compile option, then it actually showed what file had '' strings ... so I switched to # and it compiles, but, the prompts have "D" at the start of them now.(hopefully I described that understandable). Environment: Windows XP 32bit C:\FPC\3.0.4\bin\i386-Win32\fpc.exe If no one else has experienced/has a solution, I will sit down and bang out test cases until I find what combination (units, code, whatever) is producing this result. Ozz ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[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 untyped constants. Together with inlining
and optimizations this allows to generate optimal code that is yet flexible.
This feature was developed by Ryan Joseph. Thank you very much Ryan for
your contribution and your patience until this feature was included.
A generic constant parameter is declared like this:
CONSTPARAM::=const :
IDLIST::=[, ]
TYPE::=
The following types are supported for constant parameters:
- integer types (including range types)
- floating point types
- string types
- set types
- enum types
- Boolean types
- Pointer types
While the type declaration might look like a typed constant it is in
fact an untyped constant. The type is used to allow the author of a
generic to restrict the range of the type. This has some implications:
- the constant parameter can be used inside the generic whereever an
untyped constant can be used (e.g. variable initializers, constant
initializers, default parameters, array indices, compile time intrinsics
and operations)
- types that can't be used for untyped constants can't be used for
generic constant parameters either
Example:
=== code begin ===
{$mode objfpc}
type
generic TStaticArray = array[0..N-1] of T;
generic function TimesX(aArg: Integer): Integer;
begin
Result := aArg * N;
end;
var
myArray: specialize TStaticArray;
i: LongInt;
begin
i := specialize TimesX<2>(21);
end.
=== code end ===
Important: Unlike C++ FPC does not support default specializations, thus
doing recursive specializations together with operations on constants
will result in out of stack exceptions or infinite loops:
=== code begin ===
{$mode objfpc}
type
generic TTest = class
const
N1 = N - 1;
type
TSubTest = specialize TTest;
// the following does not work currently for a different reason:
// TSubTest = specialize TTest;
end;
begin
end.
=== code end ===
Delphi compatibility: this feature is NOT Delphi compatible. However to
not inconvience users that prefer mode Delphi this feature is also
available in that mode as our stance usually is that Delphi code should
compile with FPC while the inverse is not necessarily true.
Also this feature will NOT be part of 3.2.
Please give the generic constant parameters a try and report bugs in the
bugtracker.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cannot compile fpc with latest trunk on MacOSX
Am 25.04.20 um 16:46 schrieb Michael Ring via fpc-devel: make -j clean buildbase FPC=~/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh works fine with fpc checkout from a few days ago, with todays trunk I get the following error: Should be fixed. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cannot compile fpc with latest trunk on MacOSX
This has probably already been identified, but %r15 etc should be %r15d. You can't zero- extend directly to a 64-bit register because zero-extending to 32-bit is guaranteed to zero the upper 32 bits. Gareth aka. Kit On Sat 25/04/20 18:00 , "Jonas Maebe" jo...@freepascal.org sent: > On 25/04/2020 16:46, Michael Ring via fpc- devel wrote: > > > > > > /Users/ring/devel/fpc/rtl/units/x86_64- darwin/system.s:3469:15: error: > > invalid operand for instruction > > > > movzbl %r12b,%rdx > > > > sp; ^~~~ > > > Probably caused by r45057. It would be nice if the internal assembler > > were more rigorous in its checks, so it would catch these errors too. > > > > > > Jonas > > _ __ > > fpc-devel maillist - fpc- de...@lists.freepascal.org > https://lists.freepascal.org/cgi- bin/mailman/listinfo/fpc-devel > > > > > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Cannot compile fpc with latest trunk on MacOSX
On 25/04/2020 16:46, Michael Ring via fpc-devel wrote: > /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:3469:15: error: > invalid operand for instruction > movzbl %r12b,%rdx > ^~~~ Probably caused by r45057. It would be nice if the internal assembler were more rigorous in its checks, so it would catch these errors too. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
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 specialize the generic class of the first unit. Now, when I change the first unit. The changed code never makes it into my application. (This has probably to do with the interface of the first unit, which does not change) But also when I remove the original first unit, and recompile the package, but do not touch the ppu of the application, the changed code is not used. (This because the unit that belongs to the application already contains the specialized code from the first unit. It does not detect a change in the first unit, so nothings happens.) The question is: is this a known bug? If not, I can create an example and a more extensive explanation. Well, it is in so far known that I know that we have situations where recompilation doesn't happen correctly. Having a reproducible, simple example however would definitely help (the current examples that we have are always rather complex ones). Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Cannot compile fpc with latest trunk on MacOSX
make -j clean buildbase FPC=~/fpcupdeluxe/fpc/bin/x86_64-darwin/fpc.sh works fine with fpc checkout from a few days ago, with todays trunk I get the following error: /Library/Developer/CommandLineTools/usr/bin/make rtl /Library/Developer/CommandLineTools/usr/bin/make -C /Users/ring/devel/fpc/rtl 'OPT= ' all /Library/Developer/CommandLineTools/usr/bin/make -C darwin all /Users/ring/devel/fpc/compiler/ppc1 -Ur -dFPC_USE_LIBC -Ur -Xs -O2 -n -Fi../inc -Fi../x86_64 -Fi../unix -Fi../bsd -Fi../bsd/x86_64 -Fi../darwin/x86_64 -FE. -FU/Users/ring/devel/fpc/rtl/units/x86_64-darwin -dx86_64 -dRELEASE -Us -Sg ../bsd/system.pp /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:3469:15: error: invalid operand for instruction movzbl %r12b,%rdx ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:8698:16: error: invalid operand for instruction movzbl (%r14),%r13 ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:24549:15: error: invalid operand for instruction movzbl %r12b,%r15 ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:24557:15: error: invalid operand for instruction movzbl %r12b,%r15 ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:24801:15: error: invalid operand for instruction movzbl %r12b,%r15 ^~~~ /Users/ring/devel/fpc/rtl/units/x86_64-darwin/system.s:24807:15: error: invalid operand for instruction movzbl %r12b,%r15 ^~~~ system.pp(398) Error: Error while assembling exitcode 1 system.pp(398) Fatal: There were 2 errors compiling module, stopping ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Discussion: XML node dump extensions
Hi everyone, I would like to propose extending the XML node dumping feature for the compiler in order to help with development of new compiler features, especially where node optimisation is concerned (e.g. pure functions, vectorisation). Currently, I have added support to show some elements of newly-defined classes and records in the unit, mostly in order to show the byte offsets and lengths of each field (to aid vectorisation): https://bugs.freepascal.org/view.php?id=36882 One thing I like to add is to dump the node tree as it appears after the first pass, or at least right before it is converted into platform-specific assembly language, because that will allow developers to see how everything appears after simplication and node optimisation, especially if nodes are removed. My question though... considering node dumps generate many megabytes of data and a single procedure can produce a massive tree, should the optimised tree appear in the same dump file as the rest, under a different XML branch, or in a separate node dump file to make visual side-by-side comparison with the regular node dump easier? Gareth aka. Kit -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
