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

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] Deeper problem with Internal Error 200309201

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 overhead will probably offset any potential speed gains, so

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

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 methods, due to conditional defines, would compile

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

P.S. I would like Florian's approval before I start anything though, because as I've learnt with my inline assembler work, I'll just end up getting upset, melting down and burning out. Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.c

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

at, if I get them wrong, they are very easy to rename in Lazarus. On 13/07/2019 14:44, Sven Barth via fpc-devel wrote: Am 13.07.2019 um 14:12 schrieb J. Gareth Moreton: I would like some discussion on this with the administrative team because this does require some careful design if we'

[fpc-devel] Deeper problem with Internal Error 200309201

Hi everyone, So my patch to fix #32913 was unfortunately rejected because it relied on a slightly hacky feature in the form of a new state variable that, currently, is only used to patch this particular issue, and as Florian has hinted in the is

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

may not be reliable, and once again I'm implying that enums are unsafe to use, but right now, what else can one do? Gareth aka. Kit On 13/07/2019 12:28, Martin Frb wrote: On 11/07/2019 15:46, J. Gareth Moreton wrote: For my personal point of view, I would like these operators to b

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

Okay, okay.  So what do we do to stop all these bug reports and help programmers who get caught out by case blocks raising access violations?  Are you effectively saying "don't ever use enumerations for external files and network signals" etc? Gareth aka. Kit --- This email has been checked

Re: [fpc-devel] Bug fixes awaiting verification/approval

I've tried to address the issues raised by Florian in #32913, but have largely failed, outside of adding more comments.  I can't yet see any other way to implement a fix without causing a large performance penalty or a regression elsewhere, so if the patch is rejected again, I would like some h

Re: [fpc-devel] Bug fixes awaiting verification/approval

As requested by Sven on issue #32913 , a new issue, #35841 , has been split off.  They are technically two distinct bugs, although one (an error raised by the assembler) was hidden by the other (an int

Re: [fpc-devel] Bug fixes awaiting verification/approval

The other one that's been sitting around for a while is #34772 , although the issue here is that there are two mutually exclusive patches that fix the bug in different ways. Gareth aka. Kit ___ fpc-devel

[fpc-devel] Bug fixes awaiting verification/approval

Hi everyone, I just finished fixing issue #32913 that's been on my books for nearly a year now.  It turns out I didn't need the node dump feature to fix it after all, although it was still a lot more challenging than I would have given it credit

Re: [fpc-devel] Undesirable attachment to issue #29332

Let's hope it stays that way! On 12/07/2019 11:40, Bart wrote: On Fri, Jul 12, 2019 at 12:35 PM Bart wrote: One of the managers maybe can look into it. It seems that this was his only post in the bugtracker. (I filtered on "Note By") ___ fpc-deve

Re: [fpc-devel] Undesirable attachment to issue #29332

I can't quite go that far unfortunately.  Being a developer gives me the right to delete attachments and modify posts, but not to tamper with people's profiles. Gareth aka. Kit On 12/07/2019 11:26, Bart wrote: On Fri, Jul 12, 2019 at 12:12 PM J. Gareth Moreton wrote: We might wa

Re: [fpc-devel] Undesirable attachment to issue #29332

We might want to keep an eye out in case it happens again though - the last thing we want is a bot or an incredibly bored troll clogging our bug issue system. Gareth aka. Kit On 12/07/2019 11:08, J. Gareth Moreton wrote: "Paper writing service - Someone else's life as material f

Re: [fpc-devel] Undesirable attachment to issue #29332

"Paper writing service - Someone else's life as material for writing" Removed! On 12/07/2019 10:56, Bart wrote: Hi, User tomas platz attached a pdf (119.pdf) to https://bugs.freepascal.org/view.php?id=29332 This attachment seems to be a document that has nothing to do with programming (in free

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

On 11/07/2019 13:07, Michael Van Canneyt wrote: There is no "disagreement". just doubt as to what the right approach is. If the compiler assumes that an enumerated always contains a valid value, then the logical consequence is that the above "is" always evaluates to true. In that case it makes

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

On 11/07/2019 11:52, Ondrej Pokorny wrote: BTW, your note in the issue report is very misleading: https://bugs.freepascal.org/view.php?id=33603#c117162. > The idea behind "is" and "as" is that they are the sole exception to the rule and will return False and raise an error respectively if the

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

Done! On 11/07/2019 07:51, Michael Van Canneyt wrote: On Thu, 11 Jul 2019, J. Gareth Moreton wrote: Should I modify the patch to allow enumerations with holes with "is" and "as"?  Note that these operators will return True/not raise an error if a value falls within a h

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

Should I modify the patch to allow enumerations with holes with "is" and "as"?  Note that these operators will return True/not raise an error if a value falls within a hole but is otherwise between the lowest and highest elements. Gareth aka. Kit On 09/07/2019 20:19, J.

[fpc-devel] x86_64 Optimizer Overhaul

Hi everyone, I just recently updated the patches for my x86_64 Optimizer Overhaul (which also improves i386).  One thing I'm not so sure of is if I've accidentally overwritten some more recent changes to the peephole optimizer or not, which I hop

[fpc-devel] Another benefit of pure functions

This is for my own benefit and note-taking, but I've just found another use for pure functions. Though this is not exactly how the compiler source is structured, you get situations such as this. RegName := debug_regname(taicpu(p).oper[0]^.reg); { 32-bit register name } DebugMsg(SPeepholeOptim

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

Hopefully we'll get there in the end!  I've updated what I can in the patch file directly, so hopefully all is well now. Some of the variable names, like "ProcName", were already named as such. Gareth aka. Kit On 09/07/2019 10:12, Sven Barth via fpc-devel wrote: J. Gareth

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

l and to not have spaces (and all types and variables being lowercase) feels very C-like.  But hey, rules are rules... or guidelines! Is the new AS-IS-enum-08 patch any better? Gareth aka. Kit On 09/07/2019 07:03, J. Gareth Moreton wrote: I don't recall using "as" or "

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

I don't recall using "as" or "is" directly, but if I've done so, I humbly apologise and will fix that right away. Gareth aka. Kit On 09/07/2019 06:41, Sven Barth via fpc-devel wrote: Am 08.07.2019 um 02:52 schrieb J. Gareth Moreton: On an extra note, the assembl

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

I need to know exactly what's been decided upon.  No arguments, no debates, no objections.  What has been accepted as "this is what will be implemented after all parties have been heard"? Because I can't put myself into a meltdown while my neck is being wrung for not doing what people wanted.

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

Apologies.  I've been getting lost and confused in all the details and am not even sure what people want any more.  What is the consensus from the administrators? Gareth aka. Kit On 08/07/2019 21:00, Ondrej Pokorny wrote: On 08.07.2019 17:19, J. Gareth Moreton wrote: I disabled it

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

it On Mon 08/07/19 12:51 , Ondrej Pokorny laza...@kluug.net sent: > On 08.07.2019 02:37, J. Gareth Moreton wrote: > > Uploaded the latest patch (AS-IS-enum- 07.patch) over here [1] and also a > test project that evaluates the "is" operator between different ordinal > typ

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

I'm a bit late to the party again, but the example of an OpenGL shader has won me over, since game design is one thing I enjoy doing.  I guess I'm still a bit unsure how leading and trailing whitespace should be handled, but as long as it's well-documented, I think I'll be happy! Speaking of s

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

On an extra note, the assembly language produced is not yet optimal, so it may end up that an x86-specific implementation will be beneficial.  TIsNode contains a virtual method named "DoVariableEnumCheck" that would allow such an extension, coupled with returning "nil" that would defer code gen

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

Uploaded the latest patch (AS-IS-enum-07.patch) over here and also a test project that evaluates the "is" operator between different ordinal types. Following the advice of Jonas and Florian, I've removed my x86-specific code for now. Gareth aka

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

first patches are accepted and cleaned up. Gareth aka. Kit On 07/07/2019 20:07, Jonas Maebe wrote: On 07/07/2019 07:33, J. Gareth Moreton wrote: Maybe I'm missing something painfully obvious here. Can I request an example where such an invalid value/undefined behaviour crops up in bitpacke

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

e optimisations that are to be added, but I haven't worked on that in a while due to my overhaul that needs updating so it at least merges with the latest trunk and doesn't undo a load of more recent changes. Gareth aka. Kit On 07/07/2019 09:24, Florian Klämpfl wrote: Am 07.07.2019 u

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

Maybe I'm missing something painfully obvious here. Can I request an example where such an invalid value/undefined behaviour crops up in bitpacked records so I can see what's going on? Logic dictates that the number of bits required to store an enum in that arrangement is equal to the index

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

If someone has reported it, then it's not impossible.  Granted, a reproducible case helps here, along with any configuration settings. Gareth aka. Kit On 06/07/2019 03:46, Ben Grasset wrote: On Fri, Jul 5, 2019 at 10:37 PM Ryan Joseph > wrote: String constant

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

On 05/07/2019 23:50, Sven Barth via fpc-devel wrote: Am 05.07.2019 um 22:34 schrieb J. Gareth Moreton: It feels like a very convoluted way to implement a safe means of reading an enumeration from a file, but given that that reading incorrect data files is one of the main causes of enums

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

According to this , a Longint. Gareth aka. Kit On 06/07/2019 00:04, Martok wrote: I think there is a shorter version, but what is the exact return type of Ord() again? By the way, what you're reinventing here is type marshalling, for o

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

In the meantime, I've extended your AS/IS patch over here to create efficient code for x86 platforms, although currently it only does a range check and won't correctly handle enumerations with holes.  If non-contiguous enumerations are going to be

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

It feels like a very convoluted way to implement a safe means of reading an enumeration from a file, but given that that reading incorrect data files is one of the main causes of enums taking on invalid values, I have to say that this is the best solution should we not be allowed the "is" opera

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

phi mode (it'll just remove the condition and exception raise completely) but you get the idea. Gareth aka. Kit On 05/07/2019 18:28, Sven Barth via fpc-devel wrote: Pierre Muller mailto:pie...@freepascal.org>> schrieb am Fr., 5. Juli 2019, 17:51: Le 05/07/2019 à 17:42, J.

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

On 05/07/2019 15:51, Pierre Muller wrote: Just one point from current compiler implementation: in trunk/fpcsrc/compiler/ninl.pas (around line 3180) in_pred_x, in_succ_x: begin set_varstate(left,vs_read,[vsf_must_be_valid]);

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

On 05/07/2019 13:29, Sven Barth via fpc-devel wrote: J. Gareth Moreton <mailto:gar...@moreton-family.com>> schrieb am Fr., 5. Juli 2019, 14:02: I'm glad we agree on the "is" operator.  Personally I would like to extend it so it accepts "if (I is TMyEnum) the

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

Hi Michael, I'm glad we agree on the "is" operator.  Personally I would like to extend it so it accepts "if (I is TMyEnum) then" when I is also of type TMyEnum, since it may be the case that you're reading I directly from a stream, either individually or as part of a record, in which case con

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

Note, with "is" or an intrinsic that only does a range check, it can be made very fast when platform-specific.  For example, for "Result := (Value is TMyEnum);", under x86, if "l" is the Low value and "h" is the High value, then the assembly becomes this (remember that l and h are constants, so

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

Okay, I've done some preliminary testing, and "if Value < Low(TMyEnum) then" and "if Value > High(TMyEnum) then" work as expected and aren't optimised out, even when using -O4 -Cr.  So admittedly there is still a way to check to see if the enumeration is within the valid range, at least for now

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

case blocks and can trigger an access violation if a jump table is employed (this is how the compiler currently behaves), what would you propose be the best solution? Gareth aka. Kit On 05/07/2019 01:52, Michael Van Canneyt wrote: On Fri, 5 Jul 2019, J. Gareth Moreton wrote: Ah, my a

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

nneyt wrote: On Fri, 5 Jul 2019, J. Gareth Moreton wrote: It's not so much convenience... it's more the fact that the compiler can and will optimise out "if (MyValue>=ord(Low(TMyType))) and (MyValue<=Ord(High(TMyType))) then" because it has every reason to assume that

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

It's not so much convenience... it's more the fact that the compiler can and will optimise out "if (MyValue>=ord(Low(TMyType))) and (MyValue<=Ord(High(TMyType))) then" because it has every reason to assume that MyValue cannot possibly take on a value that's less than Low(TMyType) or greater tha

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

Mucking around with pointers will always produce unpredictable code if you don't take care in what you're doing (and in your example, it uses tools that already exist), but Jonas, I have to protest your logic.  Saying it's safer to refuse to do it at all instead of doing something that works pa

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 04/07/2019 06:31, Sven Barth via fpc-devel wrote: Am 04.07.2019 um 01:57 schrieb J. Gareth Moreton: While I like the idea in principle, one thing that I'm a bit worried about is how whitespace is handled, like what counts for a leading or trailing space in the string when between

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

On 04/07/2019 06:34, Sven Barth via fpc-devel wrote: Am 04.07.2019 um 01:00 schrieb Marco van de Voort: Op 2019-07-03 om 20:43 schreef Michael Van Canneyt: But the main question is: do we actually want a multiline string ? As far as I am concerned, that question needs to be answered first,

Re: [fpc-devel] Some thoughts on multi-line string support, and a possible syntax that I think is perfectly clean and Pascal-ish.

While I like the idea in principle, one thing that I'm a bit worried about is how whitespace is handled, like what counts for a leading or trailing space in the string when between lines, since Pascal parsers (and those for many other languages) traditionally, I believe, discard everything foll

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

So is the "(Value as TEnumType)" and "if (Value is TEnumType)" acceptable solutions to do a range check then the programmer absolutely needs it?  What do the administrators feel?  Not to be the bearer of bad news, but I feel like there's some disagreement. Note that things like the range check

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

Sometimes I can be too passionate for my own good, and I want FPC to continue being a great tool, without problems that prove to be a game-breaker. I would like to continue working on this particular issue and hopefully find an answer that everyone is happy with.  There are ways that an enume

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

To clarify my stance on all of this... when enumerated types are entirely internal within a program, then there is indeed no need for constant range checks like with case blocks because the value is almost always guaranteed to be valid unless you do something weird like Pointer typecasting, usi

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

On 03/07/2019 01:13, Ondrej Pokorny wrote: On 02.07.2019 23:34, Jonas Maebe wrote: As to your patch itself: why do you not directly compare the tconstexprint values directly, and use the svalue/uvalue fields instead? Because I missed that they can be directly compared directly. I dare say,

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

The main problem, Jonas, is that there will be times where the enumeration will take on a value that is outside of its domain, and often through ways that we cannot help, such as external data being in the wrong format.  I'm all for compiler optimisations assuming that the value is in range for

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

02/07/2019 21:31, Ondrej Pokorny wrote: On 02.07.2019 21:48, J. Gareth Moreton wrote: I should probably test this myself, but if you, say, read a value from a file directly into a variable of type TEnumType, will your patch return False for "if (Value is TEnumType) then" if Value, despite

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

I should probably test this myself, but if you, say, read a value from a file directly into a variable of type TEnumType, will your patch return False for "if (Value is TEnumType) then" if Value, despite being TEnumType, contains an invalid value?  No problem if it isn't, just that you would ha

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

rej. Personally, I think using 'as' to convert an integer to an enum with range check is still the best approach. It does not require new intrinsics (far too many of those already) and does what it says. To simply check if an integer is a valid enum, I think 'is' would be eq

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

Aah, thank you. On 02/07/2019 19:56, Michael Van Canneyt wrote: On Tue, 2 Jul 2019, J. Gareth Moreton wrote: I don't recall a conversation where such an intrinsic is seen as desirable, but if such a construct is desirable, then that's a good thing since it will help patch up th

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

I don't recall a conversation where such an intrinsic is seen as desirable, but if such a construct is desirable, then that's a good thing since it will help patch up this problem. As for the Delphi problem, it's second-hand information I heard from a friend who uses Delphi at work and somethi

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

Hi everyone, So there have been a lot of issues going back and forth regarding case blocks when dealing with enumerations and what happens if the enum falls outside the valid range of values for some reason, because the internal domain check is sometimes omitted for performance reasons, since

Re: [fpc-devel] atomic reads and writes

Really, insofar as x86 is concerned, the only ones that are guaranteed to be atomic are, I think, the ordinal types, but that still leaves problems of code such as the following: if GlobalCounter = 10 then begin   DoSomething;   Break; end else   Inc(GlobalCounter); If two threads are running

Re: [fpc-devel] XML node dump, how to use them?

This one is for Pierre mostly, but I've uploaded a patch to give more information on the subroutines that are dumped into the XML files. See https://bugs.freepascal.org/view.php?id=35787 for further information. Gareth aka. Kit On 26/06/2019 16:34, J. Gareth Moreton wrote: For viewin

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

In the meantime, I have some optimisations that I would be grateful could be evaluated - two of them are specific to the compiler, but one is much more general-purpose, relating to case blocks. https://bugs.freepascal.org/view.php?id=34859 https://bugs.freepascal.org/view.php?id=35346 https://b

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

; a case of strings should use a hashmap or something rather than doing one by one comparisons Cheers, Benito Am 27.06.19 um 09:27 schrieb J. Gareth Moreton: https://bugs.freepascal.org/view.php?id=35775 I'm both honoured and amused!  Thank you. Gareth aka. Kit --- This email has been ch

Re: [fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

true.  I learnt so much about nodes while developing the XML node dump feature. Gareth On 27/06/2019 08:38, Michael Van Canneyt wrote: On Thu, 27 Jun 2019, J. Gareth Moreton wrote: https://bugs.freepascal.org/view.php?id=35775 I'm both honoured and amused!  Thank you. Well, it was

[fpc-devel] "Maybe Gareth can be convinced to spend his energy on this ... "

https://bugs.freepascal.org/view.php?id=35775 I'm both honoured and amused!  Thank you. Gareth aka. Kit --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ fpc-devel maillist - fpc-devel@lis

Re: [fpc-devel] XML node dump, how to use them?

For viewing the XML files, I just use Notepad++, but if anyone has a better system or suggestion, fire away. Gareth aka. Kit On 26/06/2019 16:12, Pierre Muller wrote: Hi all, I start a new thread on the xml node dump developed by Gareth that I recently committed. I think we need at l

Re: [fpc-devel] XML node dump, how to use them?

I admit that I'm not that experienced with CSS and web-based technologies... my biggest weakness.  For the class information - that should prove no problem. Gareth aka. Kit On 26/06/2019 16:12, Pierre Muller wrote: Hi all, I start a new thread on the xml node dump developed by Gareth t

Re: [fpc-devel] XML node dump feature

https://en.wikipedia.org/wiki/Pure_function In essence, a pure function will always return the same output for a given input, analogous to a mathematical function. Gareth aka. Kit On 26/06/2019 12:18, wkitt...@windstream.net wrote: On 6/26/19 1:48 AM, J. Gareth Moreton wrote: Maybe I&#

Re: [fpc-devel] XML node dump feature

Maybe I'm misreading this, but does that mean you're not a fan of the "pure" directive, Jonas? My reasoning for including it as a directive and it not being automatic is that having the compiler determine if a function is pure or not is going to be an expensive operation and will also potentia

Re: [fpc-devel] XML node dump feature

18:55, Ryan Joseph wrote: On Jun 25, 2019, at 1:40 PM, J. Gareth Moreton wrote: This is my repository. Only one private test project so far that a friend and I are using to learn Test Driven Development and other languages. https://github.com/CuriousKit Currently I only use git locally,

Re: [fpc-devel] XML node dump feature

use GitHub in this case. Gareth aka. Kit On 25/06/2019 17:07, Ryan Joseph wrote: On Jun 25, 2019, at 11:12 AM, J. Gareth Moreton wrote: Admittedly I only just set one up, admittedly to make projects to show off to prospective employers - I haven't got anything to show yet though.

Re: [fpc-devel] XML node dump feature

While pure and inline do have a lot of overlap and, internally, probably share some features for convenience (like a copy of the node tree), they are not the same - for example, recursive functions can be pure, but not inline, and functions that dereference pointers can be inlined, but not made

Re: [fpc-devel] XML node dump feature

Admittedly I only just set one up, admittedly to make projects to show off to prospective employers - I haven't got anything to show yet though. Would you suggest I share patch files on there? Gareth aka. Kit On 25/06/2019 15:58, Ryan Joseph wrote: On Jun 25, 2019, at 4:11 AM, J. G

Re: [fpc-devel] XML node dump feature

Initially, F probably wouldn't be optimised because 'arg' is not constant.  However, if F were marked as inline (not pure) and its actual parameter is a constant (say, 5, for the sake of argument), then there is definitely potential for optimisation, since it would be expanded to the following:

Re: [fpc-devel] XML node dump feature

Honestly, I consider optimisation to be my speciality, especially given a lot of my contributions to FPC were peephole optimisations. I did think about optimisations such as "for X := 0 to SomeFunction(Para) do", where SomeFunction is a pure function, but then I was told that the upper limit i

Re: [fpc-devel] XML node dump feature

Sorry for the mistake in "RoughExp" - the first line is supposed to be "Result := 1 + X;", not "Result := Exponent;". On 25/06/2019 06:58, J. Gareth Moreton wrote: No-one said this would be an easy feature to implement.  This might be a step-by-step process,

Re: [fpc-devel] XML node dump feature

No-one said this would be an easy feature to implement.  This might be a step-by-step process, starting with simple function calls and building up to complex constant assignment. Nevertheless, at least initially, I would prefer to avoid the creation of a pure function that deals with a pointer

Re: [fpc-devel] XML node dump feature

ematical function.  If anyone has a better directive name, go for it! (Note that because it's a directive, it won't cause code to fail to compile if you happen to have a unit or identifier named 'pure'). Gareth aka. Kit On 24/06/2019 17:53, Ben Grasset wrote: On Sat, Jun 22,

Re: [fpc-devel] Record types with unbounded trailing data

t, but potentially cause excessive thrashing in a non-obvious way). On 24/06/2019 06:23, Sven Barth via fpc-devel wrote: Am 24.06.2019 um 05:57 schrieb J. Gareth Moreton: We can't really use a new keyword to define an unbounded array, so I'm wondering if we can work with the syntax for

Re: [fpc-devel] Inlining problem and LEB128

nly affecting the routine locally. Gareth aka. Kit On 24/06/2019 06:19, Sven Barth via fpc-devel wrote: Am 24.06.2019 um 01:02 schrieb J. Gareth Moreton: That's a point, true.  I've been for openness a lot lately, and one doesn't normally distribute the PPU files with a close

Re: [fpc-devel] Record types with unbounded trailing data

Thought I'd ask.  Nothing lost.  Just seeking a consensus on how to address the problem. Gareth On 24/06/2019 05:41, Michael Van Canneyt wrote: On Mon, 24 Jun 2019, J. Gareth Moreton wrote: Hi everyone, So after a problem over at https://bugs.freepascal.org/view.php?id=35753 that l

[fpc-devel] Record types with unbounded trailing data

Hi everyone, So after a problem over at https://bugs.freepascal.org/view.php?id=35753 that led to a change of https://bugs.freepascal.org/view.php?id=35671 , it became apparent that there may need to be better support for unbounded arrays in record types - not open arrays, but unbounded ones.

Re: [fpc-devel] Inlining problem and LEB128

rs in the interface section, as well as adding "inline" for methods that are short enough to warrant it (normally because their code only involves calling another method). Gareth aka. Kit On 24/06/2019 00:02, J. Gareth Moreton wrote: That's a point, true.  I've been for

Re: [fpc-devel] Inlining problem and LEB128

xed eventualy. Gareth aka. Kit On 23/06/2019 15:06, Florian Klämpfl wrote: Am 23. Juni 2019 16:05:05 schrieb Jonas Maebe : On 23/06/2019 01:10, J. Gareth Moreton wrote: Currently, you can get away with specifying the "inline" directive for a function in just the implementation secti

[fpc-devel] Inlining problem and LEB128

This one is for Jonas in particular, but also to address a minor issue in general. Currently, you can get away with specifying the "inline" directive for a function in just the implementation section of a unit, and the function will be inlined.  However, in some situations, this can cause comp

Re: [fpc-devel] XML node dump feature

Hah, indeed I can, and I will! I've noticed you're particularly keen on pure functions... what's the main use that you envision for them? Gareth On 22/06/2019 21:32, Ryan Joseph wrote: On Jun 22, 2019, at 3:56 PM, J. Gareth Moreton wrote: Thanks to Pierre's sponsor

[fpc-devel] XML node dump feature

Hi everyone, Thanks to Pierre's sponsorship and advice, the Free Pascal Compiler now contains the feature that allows you to dump the intermediate nodes generated by the compiler.  When enabled with "-dDEBUG_NODE_XML" in the compiler's source code, all units will have a "NAME-node-dump.xml" fi

Re: [fpc-devel] Pending approval...

ng point in job interviews, so I thank you and Florian for allowing me the opportunity to play around with it! Gareth aka. Kit On 18/06/2019 06:10, Pierre Muller wrote: Le 18/06/2019 à 04:21, J. Gareth Moreton a écrit : Hi everyone, So I sent my last update/fix/patch for the XML core dump feat

[fpc-devel] Pending approval...

Hi everyone, So I sent my last update/fix/patch for the XML core dump feature 3 weeks ago, but my main liaison, Pierre, seems to have vanished for the time being.  Hopefully he's okay, but it means the feature is currently in limbo and I could greatly benefit from its use in developing future

Re: [fpc-devel] Object upgrades

Ryan Joseph requested that I reply to this to show that it's in the mailing list.  Hopefully the technical problems can be resolved! Gareth aka. Kit On 15/06/2019 15:25, Ryan Joseph wrote: On Jun 12, 2019, at 9:39 AM, Ryan Joseph wrote: { resending this, I think it got lost during the ser

Re: [fpc-devel] Test

It works! Everyone's just being very quiet for some reason. On 15/06/2019 14:40, Florian Klämpfl wrote: Please ignore ... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ---

[fpc-devel] Fixes for i386/x86_64 assembler

Hi everyone, I made some fixes to the compiler when it comes to SSE and AVX instructions that deal with single (rather than packed) data, since it got the memory sizes wrong and assumed they were 128-bit or 256-bit instead.  Thanks to Marco for pointing out that it was single data in issue #3

[fpc-devel] i386 operand size quirk

Hi everyone, I'm trying to fix an issue with x86 assembly language where certain SSE and AVX instructions don't properly accept memory operands due to their size being that of a single element ( https://bugs.freepascal.org/view.php?id=32219 ).  My fixes are going okay for the most part, but I

Re: [fpc-devel] Standard generic classes

You are right George.  I'm not entirely sure what the standards are with everything, but it would be nice to have something public and concrete.  Things that already exist cannot have their API changed - they can be refactored, but as a black box it might be completely identical.  Things like c

Re: [fpc-devel] Standard generic classes

Still, the theory's there just in case... if the arguments are constant (but unknown) and the pure function is called multiple times, then it can be optimised to only be called once. Gareth aka. Kit On 06/06/2019 01:08, J. Gareth Moreton wrote: Ah, fair enough.  I didn't think to

Re: [fpc-devel] Standard generic classes

019 22:38, Sven Barth via fpc-devel wrote: J. Gareth Moreton <mailto:gar...@moreton-family.com>> schrieb am Mi., 5. Juni 2019, 18:06: *for *X := 0 *to *Min(BUFFER_SIZE, DataLeft) *- 1 do* *begin*   { Do some work that doesn't modify DataLeft } *end*; Say that Min

<    3   4   5   6   7   8   9   10   11   12   >