Re: non trivial constant folding

  genew@shuswap.net (Gene Wirchenko) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
>> genew@shuswap.net (Gene Wirchenko) writes:
>>>anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>>>>And even if the original code had undefined behaviour, a particular
>>>>compiler should implement a consistent behaviour for that, if possible
>>>>(for practical reasons, like finding the bug).
>>>
>>> Why?
>>
>>It's hard to find bugs if the behaviour changes when you try to debug
>>a program.
>
> Could be. It's more likely that the undefined behaviour will be
>consistently a certain way on a given system.


If you follow the rule above, that's the consequence.


> On a different system,
>the undefined behaviour might be different.


Yes; that's not so bad, as long as the behaviour is consistent on each
system, you can debug the program.


If you want to catch portability bugs, having differently-behaving
systems helps.


>>The compiler does not need to detect some condition in order to
>>produce consistent behaviour.
>
> Huh? How do you propose to, for example, handle overflow if it
>can't be detected?


E.g., modulo arithmetic.


Actually I was thinking more about evaluation order issues; the
compiler does not need to detect that the program depends on the
evaluation order in order to produce the same evaluation order for a
given expression. However, if it wants to optimize by reordering the
evaluation, and still wants to produce consistent behaviour, it
probably needs to detect order dependences, and suppress the
optimization (and issue a warning) if it cannot prove that there are
no order dependences.


- anton
--
M. Anton Ertl Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

Return to the comp.compilers page.
Search the comp.compilers archives again.