On Mon, Aug 26, 2013 at 11:12 AM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> Chandler Carruth <chandlerc_at_[hidden]> writes:
> | The freedom that optimizing compilers very deeply need is that the
> | ordering be totally unspecified.
>
> Is that enough for what people want when they wish for operator< to be a
> total order?

Certainly some people want to guarantee:

void foo() {
  int a;
  int b;
  assert(&a < &b);
}

but they're wrong. ;) When I suggest that < should be a total order on
pointers, I don't mean any more than what we've already specified for
std::less<T*>. The ordering should be unspecified beyond being a total
order.

> | So long as we keep this, I have no knowledge of significant negative
> | impacts on optimizing compilers. If you have other specific
> | optimizations, please bring them up (clearly, I'm not familiar with
> | all optimizing compilers! ;])
>
> See above. Note also that I've been careful making a distinction
> between "optimization" and "program transformation" -- the former appear
> to be loaded (usually with emotions both ways), while the latter
> describes a wide range of things compilers and static analysis tools do.

I think "program transformation" isn't precise enough. Certainly there
are many transformations that could rely on any piece of unspecified
behavior, but as long as they're only transformations, I have no
problem banning them. If they're also optimizations or debugging aids
or serve some other purpose, then we actually have to decide on a
trade-off.

Jeffrey