Re: [fpc-devel] Omit hint/warning for a fixed-size array

Perhaps: var Buffer: array[0..255] of Byte = Default; could be supported as shortcut for: type TByteBuffer = array[0..255] of Byte; var Buffer : TByteBuffer; begin Buffer := Default(TByteBuffer); > -Original Message- > From: fpc-devel On Behalf > Of

Re: [fpc-devel] FreeInstance

I don't think it's called anywhere in the source. It's called by the compiler after the destructor has finished. The same way that InitInstance is run before the constructor is called. This way the memory for the object is already allocated before the first constructor is run (and not only

Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development?

From: fpc-devel On Behalf Of Marcos Douglas B. Santos Sent: Monday, 30 July 2018 22:25 To: FPC developers' list Subject: Re: [fpc-devel] Why/how does the compiler have a non-trivial number ofmemory leaks after over two decades of development? On Mon, Jul 30, 2018 at 9:14 AM, Sven Barth via

Re: [fpc-devel] Compile time functions

type TMyClass = class of TMyObject; TMyObject = class procedure InstanceMethod; //Self = TMyObject, can be virtual class procedure ClassMethod; //Self = TMyClass, can be virtual class procedure StaticClassMethod; static; //no Self, really just a global procedure in a scoped

Re: [fpc-devel] Pure function Wiki page

> -Original Message- > From: fpc-devel On Behalf Of > Max Nazhalov via fpc-devel > Sent: Tuesday, 10 July 2018 02:25 > > Just one question: doesn't all this new stuff introduce another kind > of mess during cross-compiling? > > E.g. some complex nested const.expr. "sin(cos(0.12345))"

Re: [fpc-devel] Pure function Wiki page

unctions if the project is undergoing a full build). Gareth On Mon 09/07/18 01:21 , Dmitry Boyarintsev skalogryz.li...@gmail.com <mailto:skalogryz.li...@gmail.com> sent: On Sun, Jul 8, 2018 at 7:18 PM, Thorsten Engler mailto:thorsten.eng...@gmx.net> > wrote: Maybe you don’t un

Re: [fpc-devel] Pure function Wiki page

, Thorsten Engler mailto:thorsten.eng...@gmx.net> > wrote: You are thinking about something like: const x = FunctionCall(42); In which case, yes, the compiler could possibly see that as in implicit “check if that function is pure”. But “constant expressions” can also be somethin

Re: [fpc-devel] Pure function Wiki page

ure) it would fail right away. From: fpc-devel On Behalf Of Dmitry Boyarintsev Sent: Monday, 9 July 2018 08:39 To: FPC developers' list Subject: Re: [fpc-devel] Pure function Wiki page On Sun, Jul 8, 2018 at 5:43 PM, Thorsten Engler mailto:thorsten.eng...@gmx.net> > wrote: People kee

Re: [fpc-devel] Pure function Wiki page

> -Original Message- > From: fpc-devel On Behalf Of > R0b0t1 > Sent: Monday, 9 July 2018 07:22 > > There were some other comments touching on reasons for or against a > keyword, and I apologize for not speaking to them precisely. But, > this is why I would like to avoid a keyword - it is

Re: [fpc-devel] Wrong docs: not initialized global variables

> > Probably I am the only one who thinks that the code below is > ridiculous... > > > > procedure TExternalAssemblerOutputFile.AsmWriteFiltered(p: > pchar; > > len: longint); > >var > > s: ansistring; > >begin > > MaybeAddLinePrefix; > > s:=''; //

Re: [fpc-devel] Managed Types, Undefined Bhaviour

> -Original Message- > From: fpc-devel On Behalf Of > Mattias Gaertner > > > [...] COM interface methods can't logically not be virtual, > > I think you are confusing things here. They can be virtual or not > virtual in COM and CORBA. I think a lot of people simply don't understand how

Re: [fpc-devel] Managed Types, Undefined Bhaviour

> -Original Message- > From: fpc-devel On Behalf Of > Martok > Sent: Saturday, 30 June 2018 03:15 > To: fpc-devel@lists.freepascal.org > Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour > > Okay, then why does the calling convention change matters so much? > > Maybe a COM/CORBA

Re: [fpc-devel] Managed Types, Undefined Bhaviour

> -Original Message- > From: fpc-devel On Behalf Of > Michael Van Canneyt > Sent: Saturday, 30 June 2018 03:11 > To: FPC developers' list > Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour > > > Please explain. Exactly how does it demonstrate this ? > > What is the expected

Re: [fpc-devel] Managed Types, Undefined Bhaviour

> -Original Message- > From: fpc-devel On Behalf Of > Michael Van Canneyt > Sent: Saturday, 30 June 2018 01:07 > To: FPC developers' list > Subject: Re: [fpc-devel] Managed Types, Undefined Bhaviour > > what does this demo actually demonstrate other than that the compiler > functions ?

Re: [fpc-devel] Managed Types, Undefined Bhaviour

> -Original Message- > From: fpc-devel On Behalf Of > Martok > Sent: Friday, 29 June 2018 23:55 > To: fpc-devel@lists.freepascal.org > Interface functions are always virtual and implemented by the > actually instantiated class. The "override" keyword is neither > allowed nor needed,

Re: [fpc-devel] Debugging Loop Unroll Optimization

> -Original Message- > From: fpc-devel On Behalf > Of Mattias Gaertner > > You forgot the case where the loop was not entered: > > for i:=2 to 1 do ; > > i is now undefined. > > Same for > > for i in emptyset do ; Both are cases of "the loop

Re: [fpc-devel] Debugging Loop Unroll Optimization

> It is *not* undefined when the loop is left with break or exit, > that's the point. The ISO is not a very good reference for modern- > ish Pascal. I think based on both documented and observed behaviour, the following definition would be appropriate: The for-loop variable is undefined after

Re: [fpc-devel] Kit's ambitions!

From: fpc-devel On Behalf Of Wolf Sent: Friday, 18 May 2018 07:27 This is the disassembly of function GetProcessorUsed: longint;inline; Unless you advise me otherwise, I take the absence of function GetProcessorUsed: longint;inline; mentioned

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

> -Original Message- > From: fpc-devel On Behalf > Of Florian Klaempfl > Sent: Monday, 30 April 2018 04:28 > > That ended up making things worse in some cases. > > Can you take a look at the generated machine code if delphi uses > proper multi

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac functionin FPC3.1.1 / Windows x86_64

> From: fpc-devel On Behalf > Of J. Gareth Moreton > For functions with a stack frame, either LEAVE or MOV RSP, RBP; POP > RBP must precede it. It's not quite that simple, at least under windows: https://docs.microsoft.com/en-us/cpp/build/prolog-and-epilog

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

> From: fpc-devel On Behalf Of J. > Gareth Moreton > Sent: Sunday, 29 April 2018 12:36 > As an extra point, removing the 'skip' check (i.e. cmp ax, $3FE0, jbe @@skip) > removes 6 bytes from the code size and shaves about 2 to 3 nanoseconds off > the

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

> -Original Message- > From: fpc-devel On Behalf > Of Florian Klämpfl > So something like > > cmp edx, $4330 > jge @@zero > cmp edx, $3FE0 > .align 16 > jbe @@skip > > might be much better. That ended up

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

> -Original Message- > From: fpc-devel On Behalf > Of Sven Barth via fpc-devel > Thorsten, do you have tests that could go with the new > Frac() implementation? Something simply that checks the results and > does a Halt() if something is wrong

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

Basically that. For doubles that don't fit into an Int64, any fraction is beyond the significant number of digits that the double can store anyway, so 0 is the valid and correct result for Frac in that case. > -Original Message- > From: fpc-devel

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

jmp @@skip @@zero: xorpd xmm0, xmm0 @@skip: end; Cheers, Thorsten From: fpc-devel <fpc-devel-boun...@lists.freepascal.org> On Behalf Of Thorsten Engler Sent: Saturday, 28 April 2018 15:37 To: 'FPC developers' list' <fpc-devel@lists.freepascal.org> Subject: Re

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

I’ve only tested it in Delphi, so you’ll have to convert it to the right syntax for fpc, but either of these should do: function Frac1(const X: Double): Double; asm .align 16 .noframe movq rdx, xmm0 shl rdx, 32 and edx, $7FF0 cmp edx, $4330

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

n Sat, 28 Apr 2018 02:48:14 +1000 > "Thorsten Engler" <thorsten.eng...@gmx.net> wrote: > > > For what it’s worth, Delphi simply decided to give up on doing it > correctly and silently fail if the double is too large to fit in an > Int64. > >[...] > > WriteLn(F

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

; Subject: *** GMX Spamverdacht *** Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64 Thorsten Engler <thorsten.eng...@gmx.net <mailto:thorsten.eng...@gmx.net> > schrieb am Fr., 27. Apr. 2018, 18:48: For what it’s worth, Delphi simply decided to give up on doing i

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

il.com> Subject: *** GMX Spamverdacht *** Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64 Thorsten Engler <thorsten.eng...@gmx.net <mailto:thorsten.eng...@gmx.net> > schrieb am Fr., 27. Apr. 2018, 17:47: > That's true for i386. But

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

> That's true for i386. But on x86_64 cvt(t)sd2si instuctions can > deal with int64 range, if destination register is a 64-bit one. You are still going to be at least 960-bit short... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Broken frac function in FPC3.1.1 / Windows x86_64

Highest integer that fits in a Int64: 9223372036854775808 1e20: 1 Your Int is overflowing. You can’t implement Frac by going through an Integer, that will never work. Except if you have an integer that can hold 1.8E308 (which would be a 1024 bit integer, or

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

> Note that "reporter" means that somebody's not a manager of the bug > tracker. The designation covers a lot of people who are regular > contributors to- and testers of- the core FPC code, and it's > probably unfair for somebody to accuse one of them of trolling > without considering that.

Re: [fpc-devel] Broken frac function in FPC3.1.1 / Windows x86_64

> But the only responses are by a reporter named Thaddy de Koning, > which are for me totally useless and IMO he did miss the point. It's not the first time the person has been less than helpful... After looking through other issues he has commented on, I don't think he has contributed anything

Re: [fpc-devel] Dangerous optimization in CASE..OF

> -Original Message- > From: fpc-devel On Behalf Of > Martok > Sent: Saturday, 21 April 2018 21:39 > To: fpc-devel@lists.freepascal.org > Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF > > Am 20.04.2018 um 21:35 schrieb Ondrej Pokorny:

Re: [fpc-devel] Type Compatibility: dynarray <=> Pointer

A zero length dynamic array is represented by a nil pointer instead of a pointer to the heap with the information that the length of the array is 0. arr := nil; is equivalent to: SetLength(arr, 0); And the nil assignment variant is pretty much ubiquitous in any code involving dynamic arrays

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Dangerous optimization in CASE..OF

est “in” when trying to do what > you want, not “is”. > > if a in 3..10 then begin > > to me reads more accurately than > > if a is 3..10 then begin > > is the keyword is implies 1, just like the English language, > whereas, in and are implies multiple or in this case ra

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Dangerous optimization in CASE..OF

y I can see supporting is on non objects - > because we are a typed language. That was my point, not arguing > against, however, sharing a way I could see a value of it. Other > than that, I am against... > > Ozz > > > On Apr 14, 2018, at 8:38 AM, Thorsten Engler > &

Re: [fpc-devel] *** GMX Spamverdacht *** Re: Dangerous optimization in CASE..OF

ed parameter: > > procedure doSomething(myvar;out success:boolean); Begin >{… your if is comparisons …} > end; > > This opens your method to be used for all types for param1. > > Ozz > > > On Apr 14, 2018, at 5:51 AM, Thorsten Engler > <thorsten.eng..

Re: [fpc-devel] Dangerous optimization in CASE..OF

On Behalf > Of Ondrej Pokorny > Sent: Saturday, 14 April 2018 19:03 > To: fpc-devel@lists.freepascal.org > Subject: Re: [fpc-devel] Dangerous optimization in CASE..OF > > On 14.04.2018 10:39, Thorsten Engler wrote: > > How about following the same schema as with classes?

Re: [fpc-devel] Dangerous optimization in CASE..OF

How about following the same schema as with classes? If 1 is TMyEnum then //use hard cast here > -Original Message- > From: fpc-devel On Behalf > Of Ondrej Pokorny > Sent: Saturday, 14 April 2018 18:32 > To: fpc-devel@lists.freepascal.org >

Re: [fpc-devel] An extension of fpc language: the BASED construct

al.org] On > Behalf Of Karoly Balogh (Charlie/SGR) > Sent: Wednesday, 27 December 2017 03:43 > To: FPC developers' list <fpc-devel@lists.freepascal.org> > Subject: Re: [fpc-devel] *** GMX Spamverdacht *** An extension of > fpc language: the BASED construct > > HI, > &g

Re: [fpc-devel] *** GMX Spamverdacht *** An extension of fpc language: the BASED construct

> Item: BYTE BASED ItemPtr; Ignoring any other considerations for now, I would have at least used a logical extension derived from already supported syntax: Item: Byte absolute ItemPtr^; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

Re: [fpc-devel] Management operators : Copy and Clone confusion...

It's been a few years since I looked at the relevant code in the FPC compiler and RTL, so my knowledge may be woefully out of date and/or degraded by time, but IIRC: - Copy was called with a source and target pointer and is responsible for copying everything that's needed from the source to the

Re: [fpc-devel] Problem with generic parameter

Hi, Independent of what Delphi may support or not (and I agree that at a minimum in $mode Delphi fpc should not require that IFDEF)… in a modern compiler I would expect the generic type parameter to be optional in this specific scenario and the compiler infer it from the type of the

Re: [fpc-devel] Initialize/Finalize management operators and Default intrinsic

Sven Barth wrote: > In that specific example you would be right, but units are seldomly used in > isolation and once both unit1 and unit2 are used in more units it isn't that > clear (to the user) anymore which unit is initialized first. I've always found the rules about this very clear in Delphi

RE: [fpc-devel] (patch) An attempt to improve assignments/functionresult reuse

Are you sure with the strings? Yes. Any function that returns a string is supplied with one more argument than it was declared. After calling the function, register eax (which is used to contain the non-parameter result) is not used. Here is a simple example: I'am not sure but

RE: [fpc-devel] {$Interfaces Corba} and TInterfacedObject

I then wrote the following code to see if I could query for a supported interface. ... Well, the 'It worked' never appears and the cmd.Execute is never fired, so it's still a mystery how CORBA interfaces work. I'll see if Delphi help maybe mentions something. You can assign from an

RE: [fpc-devel] {$Interfaces Corba} and TInterfacedObject

AObject as ICorbaInterface ? And how does the underlying code do the lookup in the interfaces table? There is no lookup required for this. An as cast from object to interface is only allowed (at least in Delphi) if the compiler can statically at compiletime determine that the type of the

RE: [fpc-devel] {$Interfaces Corba} and TInterfacedObject

IMO borland screwed up here when they introduced IInterface = IUnknown. No they didn't. It was IMo cleaner (and you can mix interface types) There are no different types of interfaces in Delphi/Kylix. Even if there were (like there are in FPC) you can never ever mix them. when they

RE: [fpc-devel] .NET Reflection vs RTTI

Easy: look up the method in RTTI - you'll get the address. Push all arguments on the stack (see Remobjects/Innerfuse PascalScript on how to do this, you need some assembler for it), and return result value. 2 days, tops. You are funny. First, the RTTI can only give you the address of

RE: [fpc-devel] .NET Reflection vs RTTI

Apart from the custom attributes and the Invoke, I don't see what there is extra ? Sorry, forgot: No RTTI whatsoever for pointer types. Cheers, Thorsten ___ fpc-devel maillist - fpc-devel@lists.freepascal.org

RE: [fpc-devel] .NET Reflection vs RTTI

Private and protected are not your business in the first place, exposing it through RTTI or whatever is bad design. Public, OK. The class itself should have access to that information. It can then use it to e.g. stream the contents of all/some of it's private fields to/from a stream. No

RE: [fpc-devel] .NET Reflection vs RTTI

You forgot to complete: (...) but 99% of time the it just makes for useless bloat ;-) The type information required to make this work is required anyway to a) support the compilation of IL into machine code b) to allow verification of type safety and c) support the garbage collector. As such

RE: [fpc-devel] 64 Bit / 32 Bit

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Actually this is the whole core of the matter: Microsoft's developers though they could save the task switch time by not storing the fpu. However, later they discovered it was a huge security leak, and added the fpu store code. For what

RE: [fpc-devel] procedure ... message

That is the result of what is happening. Most of it is done by the library (the compiler can't do this by itself), and I am trying to use some home-brew library functions here. What I wanted to know is how the compiler does this (or how I can find out what exactly it

RE: [fpc-devel] FreeAndNil implementation

Here is an interesting reading: http://blogs.codegear.com/abauer/archive/2006/11/01/28852.aspx Maybe, the suggested FreeAndNil implementation can be usefull. See in comments. Feel free to take it... But it's x86 specific asm code... BTW: Is the bellow afirmation also valid for fpc?? we

RE: [fpc-devel] Some compiler changes...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What could be a rood reason to escape a keyword? Why do you as programmer insist on the use of a keyword? Why do you insist that your property is called 'unit'? It's just obfuscating the code. With this you can mangle your code completely...

RE: [fpc-devel] Some compiler changes...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The _ trick is widely used indeed, but imho those underscores make code slightly less readable and also less aesthetic. Less readable than ? What is the exact aesthetic ranking of [EMAIL PROTECTED]*()_+ then? :-) is an proper escaping

RE: [fpc-devel] Some compiler changes...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So instead you'd put a ? Hardly more readable, I'd say. On the contrary. _ is used already, is not. And that's exactly the reason for using and not _. It's not part of a valid identifier. If you look at: class You see directly it's the

[fpc-devel] Some compiler changes...

While playing around with the compiler source to familiarize myself I've produced the attached patch. While I didn't set out to produce anything for inclusion into the official codebase at least some of the changes might be generally useful. a) now modeswitch: m_ident_escape Allows escaping of