Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-07-14 Thread Sven Barth via fpc-devel
Am 14.07.2019 um 04:08 schrieb J. Gareth Moreton: Just a thought that I'd chuck in on this... I did wonder how practical it would be to store checksums of all compiled procedures and the like and to look for collisions.  When studying how the compiler is built, I noticed a lot of the

Re: [fpc-devel] Deeper problem with Internal Error 200309201

2019-07-14 Thread Sven Barth via fpc-devel
Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton: On another note, I do think pass_2 (pass_generate_code) could use some refactoring.  I don't like how "flowcontrol" is a global variable.  Though it's unlikely to happen, such a state variable not being tied to a management object (e.g.

Re: [fpc-devel] Deeper problem with Internal Error 200309201

2019-07-14 Thread J. Gareth Moreton
So what's the verdict so far? Do I have your blessing to start work on this? Because of its complexity, I'll do one of my PDF design specs as well. Admittedly my mind is drifting a little bit because I want to see how much optimisation can be done at the node level (e.g. converting "x * 1" to

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-07-14 Thread Jonas Maebe
On 14/07/2019 00:12, Martok wrote: > >> In Delphi's type system (and in C, C++, and C#), the valid values for an >> enum are always all values that fit within its storage size, and that >> storage size is fixed. >> >> In FPC's type system (and in Ada and Java), the valid values for an an >> enum

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-07-14 Thread Jonas Maebe
On 14/07/2019 04:08, J. Gareth Moreton wrote: > Just a thought that I'd chuck in on this... I did wonder how practical > it would be to store checksums of all compiled procedures and the like > and to look for collisions.  When studying how the compiler is built, I > noticed a lot of the internal

Re: [fpc-devel] Move operator

2019-07-14 Thread Jonas Maebe
On 13/07/2019 15:13, Ryan Joseph wrote: > > >> On Jul 13, 2019, at 8:21 AM, Jonas Maebe wrote: >> >> In which scenarios do you need such a custom "move" operator, rather >> than simply allowing the compiler to just copy the data from one place >> to the other without calling a destructor on the

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-07-14 Thread Martok
Am 14.07.2019 um 14:18 schrieb Jonas Maebe: >> Side note: if this was done 100% consistently (and it does make sense!), the >> PACKENUM directive would be completely useless. There is no point in being >> able >> to specify the storage size of an enum when it can be and is ignored at will. > >

Re: [fpc-devel] Move operator

2019-07-14 Thread Ryan Joseph
> On Jul 14, 2019, at 8:55 AM, Jonas Maebe wrote: > > The question then still remains: why would a user want to call a copy > operator when the data is just moved from a temp to another place? > Having an explicit copy operator when there is no use case for it only > requires programmers to

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-07-14 Thread Jonas Maebe
On 14/07/2019 15:53, Martok wrote: > Am 14.07.2019 um 14:18 schrieb Jonas Maebe: >>> Side note: if this was done 100% consistently (and it does make sense!), the >>> PACKENUM directive would be completely useless. There is no point in being >>> able >>> to specify the storage size of an enum when

Re: [fpc-devel] Move operator

2019-07-14 Thread Michael Van Canneyt
On Sun, 14 Jul 2019, Ryan Joseph wrote: On Jul 14, 2019, at 8:55 AM, Jonas Maebe wrote: The question then still remains: why would a user want to call a copy operator when the data is just moved from a temp to another place? Having an explicit copy operator when there is no use case for

Re: [fpc-devel] [Suggestion] Enumeration range-check intrinsic

2019-07-14 Thread Martok
> If you want to nitpick, the compiler will perform 1/2/4 byte writes for > enums of those sizes, so the full reserved data is in fact > used/initialised. Again: the only relevant part in this discussion is > the valid values. The reserved/used/accessed/written/... storage size is > unrelated to

Re: [fpc-devel] Deeper problem with Internal Error 200309201

2019-07-14 Thread J. Gareth Moreton
Looks like we have a deal then!  Break away code from "pass_1" into "pass_semantic". Thanks for your support Florian - I'll start making plans. Gareth aka. Kit On 14/07/2019 19:45, Florian Klämpfl wrote: Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton: So having a long think over the past

Re: [fpc-devel] Move operator

2019-07-14 Thread Ryan Joseph
> On Jul 14, 2019, at 11:58 AM, Michael Van Canneyt > wrote: > > You are assuming here that there is a problem. Has it occurred to you that > maybe there is no problem and that a solution is simply not needed? How is this not a problem? Sorry I don’t follow you. Regards, Ryan Joseph

Re: [fpc-devel] Deeper problem with Internal Error 200309201

2019-07-14 Thread Florian Klämpfl
Am 14.07.2019 um 04:25 schrieb J. Gareth Moreton: > So having a long think over the past day, I'm starting to turn against the > second idea I had because it would require > complex state variable tracking and is just asking for a new bug to be > introduced, not to mention that the additional >

Re: [fpc-devel] Move operator

2019-07-14 Thread Michael Van Canneyt
On Sun, 14 Jul 2019, Ryan Joseph wrote: On Jul 14, 2019, at 11:58 AM, Michael Van Canneyt wrote: You are assuming here that there is a problem. Has it occurred to you that maybe there is no problem and that a solution is simply not needed? How is this not a problem? Sorry I don’t

Re: [fpc-devel] Move operator

2019-07-14 Thread Ryan Joseph
> On Jul 14, 2019, at 12:40 PM, Michael Van Canneyt > wrote: > > Maybe there is no need for a move operator ? I have not seen any argument > that makes the need for this operator crystal clear. > > When I read your proposal, my first thought was: "solution looking for a > problem." Look at