Ada front-end depends on signed overflow

[Paul Schlie]

> From: Bernd Schmidt <bernds_cb1@t-online.de>
> Paul Schlie wrote:
>>> From: Robert Dewar <dewar@adacore.com>
>>> You keep saying this over and over, but it does not make it true. Once
>>> again, the whole idea of making certain constructs undefined, is to
>>> ensure that efficient code can be generated for well defined constructs.
>> 
>> - Can you give an example of an operation which may yield an undefined
>>   non-deterministic result which is reliably useful for anything?
> 
> The simplest example is a shift operation, x << n, where the compiler
> may assume that the shift count is smaller than the width of the type.
> All sane machines agree on shift behaviour for 0 <= n < width, but there
> are differences between machines for n >= width.  Since this case is
> undefined by the language, it is ensured that shifts take only a single
> instruction on essentially all machines.

- How is it necessary or desirable to define that the result is undefined
  vs. being target defined? As undefined seems to be presumed to give an
  implementation the license to presume it will yield any specific value
  it chooses (such as 0 for example, and presume that value in subsequent
  optimizations), where the target implementation may actually yield
  something reliably different?

  For example given that an implementation knows how a runtime value
  shift value will be treated, it seems much more reasonable to treat
  compile time constant shift values consistently, as otherwise constant
  variable values will have different different semantics effects than
  non-constant variable values may? (Which doesn't seem like a good thing,
  or strictly necessary to enable an arbitrary implementation to efficiently
  implement consistent bit-shift semantics although it's behavior beyond
  implementation-independent bounds may differ between differing
  implementations?)