Jeffrey Yasskin <jyasskin_at_[hidden]> writes:

| 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. ;)

I know, but wait till you get there :-)
People already have that assurance for non-static members.

| 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.

"program transformation" in the sense of mapping set of defined behavior
into set defined behaviour. People rarely rail against the debugger
when it catches them doing something that is undefined; they are more
likely to rail against "optimizer" when the optimizer optimizes
the "wrong code". Now imagine, the optimizer is optimizing for
safety/security as opposed to code size of number of cycles it takes
to execute a certain function with certain inputs. That is why I said
"optimization" tends to be associated with more emotion and expectations.


-- Gaby