> Richard Kenner wrote: > ... > In other words, -fwrapv says that we are modifying the language semantics > to define signed overflows as wrapping and this will have effects on the > optimizer (so the language effect is primary), while -fno-strict-aliasing > says what the optimizer will do and hence how we're modifying the language > (meaning the optimizer effect is primary). > ...
> Robert Dewar wrote: > ... > Note Paul that I think you may be confusing what I say, when I talk > about language semantics, I am talking about the formal semantics of > the language, which may well have non-deterministic, undefined, or > implementation defined elements. I am NOT talking about preserving > observed behavior. You have rather consistently confused the two. > ... > No, that's completely wrong, overflow is undefined in the semantics, so > preserving undefined semantics has nothing whatever with preserving > observed behavior for these programs with undefined semantics. Here > is exactly where you are confusing behavior with semantics. > ... Any any choice/presumption of a signed overflow semantics alters the languages specification (including the presumption of it's absents) as it's semantics are undefined. Given the controversy surrounding the issue is seems rooted in that some optimizations enabled by default at -O1/O2 modify the expressed semantics in ways that have been shown to be counterproductive (regardless of their strictly formal validity), the issue is whether or not such optimizations should be enabled to by default at these generically specifiable optimization levels. (for example, first in effect supporting wrapping semantics in absents of optimization, then presuming their absents during optimization). In other words, although the standard enables latitude in these choices, once an implementation has chosen a set of semantics by way of defining a mapping to a target's instruction set; should the expressed semantics be preserved? Personally the answer is clearly yes within reason, and only modified by explicit request otherwise through -O2. (As otherwise, the optimizations are in effect modifying the semantics of the chosen implementation, which although beneficial in some circumstances, may be clearly counterproductive in others; although all being strictly legitimate). As strict aliasing presumptions may in fact alter the expressed semantics; this too should arguably only be enabled by explicit request through -O2 to be consistent with the philosophy if adopted. I appreciate that my views/presumptions may be so inconsistent with the status quo that they are untenable; and as I feel I've expressed my thoughts as best I can, I'll leave the issue to rest and hopeful resolution to those who know better.
