|[15 earlier articles]|
|Re: non trivial constant folding email@example.com (Dennis Ritchie) (2001-01-11)|
|Re: non trivial constant folding ONeillCJ@logica.com (Conor O'Neill) (2001-01-11)|
|Re: non trivial constant folding firstname.lastname@example.org (2001-01-18)|
|Re: non trivial constant folding email@example.com (2001-01-18)|
|Re: non trivial constant folding firstname.lastname@example.org (2001-01-19)|
|Re: non trivial constant folding email@example.com (2001-01-20)|
|Re: non trivial constant folding firstname.lastname@example.org (2001-01-26)|
|Re: non trivial constant folding email@example.com (Hans-Bernhard Broeker) (2001-02-01)|
|From:||firstname.lastname@example.org (Anton Ertl)|
|Date:||26 Jan 2001 16:58:05 -0500|
|Organization:||Institut fuer Computersprachen, Technische Universitaet Wien|
|References:||01-01-015 01-01-022 01-01-033 01-01-090 01-01-108 01-01-129|
|Posted-Date:||26 Jan 2001 16:58:05 EST|
email@example.com (Gene Wirchenko) writes:
>firstname.lastname@example.org (Anton Ertl) wrote:
>> email@example.com (Gene Wirchenko) writes:
>>>firstname.lastname@example.org (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).
>>It's hard to find bugs if the behaviour changes when you try to debug
> 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
>>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.
M. Anton Ertl Some things have to be seen to be believed
email@example.com Most things have to be believed to be seen
Return to the
Search the comp.compilers archives again.