<p>Am 22.09.2014 14:31 schrieb "Hans-Peter Diettrich" <<a href="mailto:DrDiettrich1@aol.com">DrDiettrich1@aol.com</a>>:<br>
><br>
> Marco van de Voort schrieb:<br>
><br>
>> (to Sven)<br>
>><br>
>> So the cycle break mechanism is going to be marking potential cycle cases<br>
>> as weak.<br>
>><br>
>> Do you still plan to at least detect cycles for debugging purposes?<br>
>><br>
>> Or is the cycle detection itself already too hard?<br>
>><br>
>> IOW I'm wondering what will happen (and what to do) if there is a cycle in a<br>
>> sufficiently complex program.<br>
><br>
><br>
> I could imagine a tool for that purpose, instead of burdening the compiler with such rarely used functionality. More diagnostics could be removed from the compiler, like the detection of unused local variables or units - if that helps to speed up compilation. Separate diagnostic tools could immediately offer means to solve the detected problems interactively, what's not the purpose of an compiler.</p>
<p>These diagnostics help the compiler to remove application code it doesn't need to generate. So why should I remove them? Also these diagnostics are quite fast already. Other more costly optimizations are already optional using the -Ox options.</p>
<p>Additionally the cycle detection algorithm wouldn't be run at compiletime anyway, but at runtime. Namely during every reference count decrease.</p>
<p>Regards,<br>
Sven</p>