6 ms·

> given appropriate very specific input data That's the operative words there. Compilers are not required to ensure that, in sufficiently perverse circumstance

by a1369209993 5y ago

> given appropriate very specific input data That's the operative words there. Compilers are not required to ensure that, in sufficiently perverse circumstances, undefined behaviour never results in demons flying out of you nose. They are, however, required to not actively put said demons there themselves, because that's part of what distinguishes a programming language implementation from a piece of malware masquerading as a programming language implementation.

saagarjha 5y ago
Compilers never actively try to put demons in your program. However, they do occasionally end up making constructs that result from a reasonable (if not the most well-thought-out) chain of decisions that end up looking like demons to the untrained eye.
- a1369209993 5y ago
  I didn't say "try"; if it quacks like demon, it's a demon, and the implementation is (whether the standards commitee likes it or not) required not to actively put it into programs that didn't already have it[0], deliberately or otherwise. 0: like this one: int* zero = 0; int bad = *zero; // maybe crash lol if(!zero) abort(); // definitely crash lol printf("Uln nasaloth geb hai!\n");
  - d110af5ccf 5y ago
    It just isn't that simple in practice. Modern compilers automatically apply a plethora of different rules in sequence when transforming code. This results in a long chain of transformations where each operation is perfectly reasonable when considered on its own. Unfortunately, for certain inputs, the sum total occasionally appears demonic. The current state of the art is such that there is no way to reliably prevent this that doesn't also severely reduce the optimization abilities of modern compilers. Realistically, adding such language to the standard would (at best) result in worse optimizations by default and additional compiler flags to reenable the more aggressive "nonstandard" ones. (Such flags already exist for various arithmetic operations.)
    - a1369209993 5y ago
      > where each operation is perfectly reasonable when considered on its own. No, it is not. For example, the transformation: int read_and_discard = *p; // vvvv int read_and_discard = *p; __unsafe_assume_always(p != 0); is not reasonable, since p is not, in fact, always nonnull.
      - d110af5ccf 5y ago
        Your examples are far too simplistic. Real world code is going to be far more complex and will tend to resist trivial analysis. For example, please explain how to prevent this without also (inadvertently) preventing the removal of unnecessary null checks when functions are inlined. What about an unnecessary null check that's hidden inside a macro? What about whole program LTO? A macro could be used in a variety of situations. In some of them, you need the null check for safety. In others, the null check in entirely redundant. Short of AGI, the compiler can't actually comprehend the code it operates on. Yet surely you expect it to eliminate "obviously" redundant work? It accomplishes this by applying a large set of fairly simple rules. (There are probably much better examples but I can't think of them off the top of my head.) In practice, when I play with Godbolt I find that the "obvious" cases tend to result in helpful diagnostic messages.
        a1369209993 5y ago
        > For example, please explain how to prevent this without also (inadvertently) preventing the removal of unnecessary null checks when functions are inlined. What about an unnecessary null check that's hidden inside a macro? If a null check is unnecessary, that's because it is reachable only from the not-null side of some previous null check. The compiler can track that information just fine, using the same tools it uses to track false information derived pointer dereferences. If: if(!p) abort(); // we know p is non-null here, regardless of the dereference use(*p); MACRO(p); expands to: if(!p) abort(); // first null check (this is relevant to optimizing out unnecessary null checks) use(*p); // pointer dereference (this isn't) if(!p) abort(); // second null check (unnecessary *because of the if*) utilize(*p); // more pointer dereference the compiler can optimize out the second if (the "unnecessary null check" you refer to) based on the first if, regardless of whether the pointer dereference is even there.

saagarjha 5y ago

Compilers never actively try to put demons in your program. However, they do occasionally end up making constructs that result from a reasonable (if not the most well-thought-out) chain of decisions that end up looking like demons to the untrained eye.

a1369209993 5y ago
I didn't say "try"; if it quacks like demon, it's a demon, and the implementation is (whether the standards commitee likes it or not) required not to actively put it into programs that didn't already have it[0], deliberately or otherwise. 0: like this one: int* zero = 0; int bad = *zero; // maybe crash lol if(!zero) abort(); // definitely crash lol printf("Uln nasaloth geb hai!\n");
- d110af5ccf 5y ago
  It just isn't that simple in practice. Modern compilers automatically apply a plethora of different rules in sequence when transforming code. This results in a long chain of transformations where each operation is perfectly reasonable when considered on its own. Unfortunately, for certain inputs, the sum total occasionally appears demonic. The current state of the art is such that there is no way to reliably prevent this that doesn't also severely reduce the optimization abilities of modern compilers. Realistically, adding such language to the standard would (at best) result in worse optimizations by default and additional compiler flags to reenable the more aggressive "nonstandard" ones. (Such flags already exist for various arithmetic operations.)
  - a1369209993 5y ago
    > where each operation is perfectly reasonable when considered on its own. No, it is not. For example, the transformation: int read_and_discard = *p; // vvvv int read_and_discard = *p; __unsafe_assume_always(p != 0); is not reasonable, since p is not, in fact, always nonnull.
    - d110af5ccf 5y ago
      Your examples are far too simplistic. Real world code is going to be far more complex and will tend to resist trivial analysis. For example, please explain how to prevent this without also (inadvertently) preventing the removal of unnecessary null checks when functions are inlined. What about an unnecessary null check that's hidden inside a macro? What about whole program LTO? A macro could be used in a variety of situations. In some of them, you need the null check for safety. In others, the null check in entirely redundant. Short of AGI, the compiler can't actually comprehend the code it operates on. Yet surely you expect it to eliminate "obviously" redundant work? It accomplishes this by applying a large set of fairly simple rules. (There are probably much better examples but I can't think of them off the top of my head.) In practice, when I play with Godbolt I find that the "obvious" cases tend to result in helpful diagnostic messages.
      - a1369209993 5y ago
        > For example, please explain how to prevent this without also (inadvertently) preventing the removal of unnecessary null checks when functions are inlined. What about an unnecessary null check that's hidden inside a macro? If a null check is unnecessary, that's because it is reachable only from the not-null side of some previous null check. The compiler can track that information just fine, using the same tools it uses to track false information derived pointer dereferences. If: if(!p) abort(); // we know p is non-null here, regardless of the dereference use(*p); MACRO(p); expands to: if(!p) abort(); // first null check (this is relevant to optimizing out unnecessary null checks) use(*p); // pointer dereference (this isn't) if(!p) abort(); // second null check (unnecessary *because of the if*) utilize(*p); // more pointer dereference the compiler can optimize out the second if (the "unnecessary null check" you refer to) based on the first if, regardless of whether the pointer dereference is even there.