[fpc-devel] Deeper problem with Internal Error 200309201

[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 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 the cleaner, simple solution sounds far more appealing now.
>> Also, when it comes to dead nodes (an except section that gets removed or any code following "Exit" in the same block),
>> there's nothing to stop the compiler from deleting the nodes completely, since semantics have already been checked (and
>> maybe chucking in an extra "unreachable code" warning if needs be), thus pruning the tree and making the process faster
>> for pass_generate_code.
>>
>> I do wonder why 'simplify' is a distinct method though, because a lot of the time one can simply put its code at the end
>> of 'pass_1' and there wouldn't be any difference in functionality (plus what counts as 'pass_1' and what counts as
>> 'simplify' is often left to the programmer's discretion) while nodes that have more complex simplification, like
>> taddnode, could use their own private methods.  It might be something for me to experiment with on the side.
> The idea is to keep passes distinct. It makes maintainace easier. Besides this, Simplify is made to be run multiply
> times, pass_1 not.
>
>> So the node parsing overhaul, so far...
>>
>> - pass_semantic
> Yes.
>
>> - pass_transform (what was "pass_1")
> I wouldn't change this in one patch. Step by step ...
>
>> - simplify (if not merged into the above)
>> - pass_generate_code (I won't touch this for now)
>>
>> 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.
>> current_procinfo) prevents the compiler from being multi-threaded, at least for that pass.
>>
>> Gareth aka. Kit
>>
>> P.S. Anyone got a better name for "pass_transform"?
> pass_1 was for years, I wouldn't change it for the time being.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus