> Gabriel Dos Reis wrote: > I predict we will end up changing nothing for GCC; I also predict that > he'll be unsatisfied with unsupported claims; then, there is a high > chance the discussion will be restarted again in a different form > (hey, this is not the first time you, Paul and me are involved in this > kind of undefined discussion). If we have good answers with backed up > claims, we could just reference it later. > ... > I think supported answers will help diminish undefined disucssion frequency. > If you don't have a definition for "good reason", that is fine. Let's move > on something else; this is a new year.
Gentlemen, I honestly don't want to promote a frivolous debate either; as such, if it is generally agreed there are no valid conceivable reasons to enable GCC to allow a target to specify the semantics of its particular implementation to enable optimizers to utilize that information such that its otherwise non-optimized behavior may be preserved during optimization, then I simply accept that I'm alone in the believe of its significance and utility; if not, then it seems that the only questions remaining are related to how may this be done relatively easily within the current optimization and target definition framework? If specific examples are required, although likely considered obvious, here's a few: - x[y] = 0; // may also be undefined if y is one past the if (x[y]) y = y+1; // extent of x[], and/or result in an overflow // of x[y] one past the it's upper bound if // allocated at the upper range of the address // space, and/or if allocated at the base // address of 0 and y is 0 or negative; but // non-the less the machine evaluating the code // will do something which is likely well // defined, and must be defined if that logical // behavior is to be predictable and thereby // preferable during optimization. - x = 5 << z; // where although implementation specific, must if (x > 0) z = 2; // to be definable if to be utilized as the // basis of a target specific behavior // preserving optimization.