Gabriel Dos Reis writes:
> Steven Bosscher <[EMAIL PROTECTED]> writes:
>| On Tuesday 28 June 2005 07:12, Gabriel Dos Reis wrote:
>| > For the concrete case at issue, if the hardware I'm writing the C/C++
>| > programs for consistently displays modulo arithmetics for signed
>| > integer type, Andrew can you tell me why GCC should deny me access
>| > to that functionally where it actually can?
>|
>| Because it disallows compiler transformations? E.g. suddenly a
>| loop with a signed variable as the loop counter may wrap around,
>| which that means some transformations that are safe now would
>| no longer be safe.
>
> You have to define "safe". Obviously, if you make the assumption that
> with signed overflow, all bets are off then you can go to
> tansformations predicated by that assumption. If you take the
> assumption that signed overflow is defined and supported, you can go
> transformations predicated by that assumption. In either case, "safe"
> is with respect to the semantics chosen.
Yes.
Overall the problem/conflict seems to revolve around the differentiation
between what's allowed vs. should be done; where "should" is of course
subjective, so it may be worth first attempting to define philosophically
what an idealized implementation "should" do, and then strive to follow this
guideline in cases where the compiler has the freedom to do so.
For what it's worth, a compiler "should":
- Strictly implement all mandated language semantics by default; although
may enable these semantics to be extended and/or altered, if believed to
be "Most Likely Beneficial", only by explicit request to do so.
- Define and correspondingly strictly implement the "Most Likely Beneficial"
semantics which are not mandated by the standard as if they were, and
emit a warning for every such behavior which is known to likely to express
itself. (i.e. a shift by a value known to have a range which may exceed
the size of it's shifted operand, or a the dereference of a pointer which
is known to potentially be NULL, for example.)
- Where the "Most likely Beneficial" semantics are those which most likely:
- improve the expressiveness and/or consistency of the language.
- improve the determinism of the language and resulting executable.
- improve the efficiency of the language and resulting executable by
adopting and basing optimizations on the target's native semantics
when not in conflict with the above.
Thereby it's never "Most likely Beneficial" to base optimizations on a
presumed undefined behavior, as no such behaviors should exist; therefore
such optimizations will only likely yield inconsistent and/or potentially
non-deterministic results, which is most likely not beneficial toward the
goals of producing an efficient deterministic program.
(The key to an efficient, consistent, and deterministic compiled program is
leveraging the natural behavior of the target where it is not in conflict
with the language's or implementation's otherwise defined semantics.)
