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

Note that there is possible room for improvement with this concept (like maybe only running the semantic check on nodes that exist before the first pass, not executing it on any transformed nodes), but I wanted to get something clean working first, and fix the bugs that have been on the system

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

I've completed my work, although I had to adapt the original plan slightly, and I feel like my design spec could use some rewriting in places.  Think of it as code smell for writing! https://bugs.freepascal.org/view.php?id=35857 - the PDF design spec is here. Gareth aka. Kit --- This email

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

So a progress update. I ended up running into some difficulty with the original idea of having a full semantic pass that is run prior to the first pass. For some reason, "pass_semantic" wasn't always executed for every node, and I still haven't figured out why (although it seems to be related

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

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

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] 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

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

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,

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.

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

Points seem fair so far.  And true, the Boolean result won't be necessary because the error flag will be set, and this can be checked instead. While the idea behind "pass_1" and "simplify" are different, to me it isn't always clear what is simplification and what is regular code pass, and is

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

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're going to do this properly.  Building on Florian's suggestion, I would like to propose splitting "pass_1" into "pass_syntax"

[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