On Mon, 7 Mar 2005, Richard Henderson wrote: > On Mon, Mar 07, 2005 at 08:55:14AM -0700, Roger Sayle wrote: > > For rvalue MIN_EXPR and rvalue MAX_EXPR, the semantics need > > to specify a reference to the first operand is returned for values > > comparing equal. > > NOT true. And the docs explicitly say so.
Which docs?! There's currently *no* documentation for MIN_EXPR or MAX_EXPR in c-tree.texi. Indeed the only references to these within the entire docs subdirectory is for calling REAL_ARITHMETIC. And the commentary above MIN_EXPR and MAX_EXPR in tree.def also has absolutely nothing to say on the matter. Even the descriptions of the extensions ">?" and "<?" in extend.texi, don't describe the behavior of equal comparions! However, to support my of side of argument I refer you to the comment at line 4294 of fold-const.c: > /* In C++ a ?: expression can be an lvalue, so put the > operand which will be used if they are equal first > so that we can convert this back to the > corresponding COND_EXPR. */ And as an example of why this is relevant, see bugzilla PR c++/7503, particularly the example in comment #1. As has been described earlier on this thread, GCC has folded the C++ source "(a >= b ? a : b) = c" into "MAX_EXPR (a,b) = c" and equivalently "(a > b ? a : b) = c" into "MAX_EXPR (b,a) = c" since the creation of current CVS. The correct behavior of this code relies on (and has always relied on) the fact that the middle-end prescribes a behaviour for equal comparison. In balance, to support your side of the argument, ever since the same creation of current CVS, the middle-end has considered MIN_EXPR and MAX_EXPR to be commutative operations. We're screwed if we do and screwed if we don't. Basically the lvalue forms of these tree nodes have different algebraic properties to the rvalue forms. I'm looking forward to any clarification you can make to your comments. Roger --
