Re: Ada front-end depends on signed overflow

[Florian Weimer <fw at deneb dot enyo dot de>]

* Paul Schlie:

> - I'm not attempting to design a language, but just defend the statement
>   that I made earlier; which was in effect that I contest the assertion
>   that undefined evaluation semantics enable compilers to generate more
>   efficient useful code by enabling them to arbitrarily destructively alter
>   evaluation order of interdependent sub-expressions, and/or base the
>   optimizations on behaviors which are not representative of their target
>   machines.

But the assertion is trivially true.  If you impose fewer constraints
on an implementation by leaving some cases undefined, it always has
got more choices when generating code, and some choices might yield
better code.  So code generation never gets worse.

Whether an implementation should exercise the liberties granted by the
standard in a particular case is a different question, and has to be
decided on a case-by-case basis.

>   (With an exception being FP optimization, as FP is itself based
>    only on the approximate not absolute representation of values.)

FP has well-defined semantics, and its absolutely required for
compilers to implement them correctly because otherwise, a lot of
real-world code will break.

Actually, this is a very interesting example.  You don't care about
proper floating point arithmetic and are willing to sacrifice obvious
behavior for a speed or code size gain.  Others feel the same about
signed integer arithmetic.

>>> - Agreed, I would classify any expression as being ambiguous if any of
>>>   it's operand values (or side effects) were sensitive to the allowable
>>>   order of evaluation of it's remaining operands, but not otherwise.
>> 
>> But this predicate cannot be evaluated at compile time!
>
> - Why not?

In general, it's undecidable.

>   The compiler should be able to statically determine if an
>   expression's operands are interdependent, by determining if any of
>   its operand's sub-expressions are themselves dependant on a variable
>   value potentially modifiable by any of the other operand's sub-
>   expressions.

Phrased this way, you make a lot of code illegal.  I doubt this is
feasible.