3 ms·

Well, it is more complicated than that. First of all compilers disagree on many interpretations and consequences of abstract machine rules. Also compilers hav

Well, it is more complicated than that. First of all compilers disagree on many interpretations and consequences of abstract machine rules. Also compilers have bugs. So a proficient C/C++ programmer does have to learn what compilers actually do in practice and what they guarantee beyond the standard (or how they differ from it). > C/C++ isn't a language. It isn't, but it is a family of languages that share a lot of syntax and semantics.

Arch-TK 2y ago
> First of all compilers disagree on many interpretations and consequences of abstract machine rules. List them. I am not aware of any well defined parts of the C standard where GCC and Clang disagree in implementation. Only in areas where things are too vague (and are effectively either unspecified or undefined), or understandably in areas where they're "implementation defined". If there are behaviours where a compiler deviates from the standard it is either something you can configure (e.g. -ftrapv or -fwrapv) or it's a bug. > Also compilers have bugs. Nothing you do can defend against compiler bugs outside of extensively testing your results. If you determine that a compiler has a bug then the correct course of action is definitely not: "note it down and incorporate the understanding into your future programs" > So a proficient C/C++ programmer does have to learn what compilers actually do in practice and what they guarantee beyond the standard (or how they differ from it). There are situations where it's important to know what the compiler is doing. But these situations are limited to performance optimisation, the knowledge gained through these situations should only be applied to the single version of the compiler you observed it in, and you should not use the knowledge to feed back to your understanding of C or the implementation. It's almost impossible to decipher how modern C compilers work exactly and trying to determine what an implementation does based on the results of compilation is therefore extremely unreliable. If you need to rely on implementation defined behaviour (unavoidable in any real program) then you should be relying solely on documentation, and if the observed behaviour deviates from the documentation then that is, again, a bug bug. > It isn't, but it is a family of languages that share a lot of syntax and semantics. I am not a C/C++/C#/ObjectiveC/JavaScript/Java programmer. C++ and C might share a lot of syntax but that's basically where the similarities end in any modern implementation. People who know C thinking they know enough C to write reliable and conformant C++ and people who know C++ thinking they know enough C++ to write reliable and conformant C are one of the groups of people who produce the most subtle mistakes in these languages. I think you could get away with these kinds of things in the 80s but that has definitely not been the case for quite a while.
- AlotOfReading 2y ago
  > List them. I am not aware of any well defined parts of the C standard where GCC and Clang disagree in implementation. Perhaps it's not "well defined" enough for you, but one example I've been stamping out recently is whether compilers will combine subexpressions across expression boundaries. For example, if you have z = x + y; a = b * z; will the compiler optimize across the semicolon to produce an fma? GCC does it aggressively, while Clang broadly will not (though it can happen in the LLVM backend).
  - Arch-TK 2y ago
    You're very right that this goes above and beyond anything the C standard specifies aside from stating that the end result should be the same as if the expressions were evaluated separately (unless you have -ffast-math enabled which makes GCC non-conformant in this regard). If the end result of the calculation differ (and remember that implementations may not always use ieee floats) then you can call it a bug in whatever compiler has that difference.
    - gpderetta 2y ago
      as it was pointed out to me recently, GCC will happily generate MADs even in standard conforming modes (in c++ at least).
      - Arch-TK 2y ago
        I have no idea how C++ defines this part of its standard but from experience it's likely that it's different in some more or less subtle way which might explain why this is okay. But in the realm of C, without -ffast-math, arithmetic operations on floats can be implemented in any way you can imagine (including having them output to a display in a room full of people with abaci and then interpreting the results of a hand-written sheet returned from said room of people) as long as the observable behaviour is as expected of the semantics. If this transformation as you describe changes the observable behaviour had it not been applied, then that's just a compiler bug. This usually means that an operation such as: double a = x / n; double b = y / n; double c = z / n; printf("%f, %f, %f\n", a, b, c); Cannot be implemented by a compiler as: double tmp = 1 / n; double a = x * tmp; double b = y * tmp; double c = z * tmp; printf("%f, %f, %f\n", a, b, c); Unless in both cases the same exact value is guaranteed to be printed for all a, b, c, and n. This is why people enable -ffast-math.
tomjakubowski 2y ago
One of the places where C and C++ differ in semantics is in their strict aliasing rules.

Arch-TK 2y ago

> First of all compilers disagree on many interpretations and consequences of abstract machine rules. List them. I am not aware of any well defined parts of the C standard where GCC and Clang disagree in implementation. Only in areas where things are too vague (and are effectively either unspecified or undefined), or understandably in areas where they're "implementation defined". If there are behaviours where a compiler deviates from the standard it is either something you can configure (e.g. -ftrapv or -fwrapv) or it's a bug. > Also compilers have bugs. Nothing you do can defend against compiler bugs outside of extensively testing your results. If you determine that a compiler has a bug then the correct course of action is definitely not: "note it down and incorporate the understanding into your future programs" > So a proficient C/C++ programmer does have to learn what compilers actually do in practice and what they guarantee beyond the standard (or how they differ from it). There are situations where it's important to know what the compiler is doing. But these situations are limited to performance optimisation, the knowledge gained through these situations should only be applied to the single version of the compiler you observed it in, and you should not use the knowledge to feed back to your understanding of C or the implementation. It's almost impossible to decipher how modern C compilers work exactly and trying to determine what an implementation does based on the results of compilation is therefore extremely unreliable. If you need to rely on implementation defined behaviour (unavoidable in any real program) then you should be relying solely on documentation, and if the observed behaviour deviates from the documentation then that is, again, a bug bug. > It isn't, but it is a family of languages that share a lot of syntax and semantics. I am not a C/C++/C#/ObjectiveC/JavaScript/Java programmer. C++ and C might share a lot of syntax but that's basically where the similarities end in any modern implementation. People who know C thinking they know enough C to write reliable and conformant C++ and people who know C++ thinking they know enough C++ to write reliable and conformant C are one of the groups of people who produce the most subtle mistakes in these languages. I think you could get away with these kinds of things in the 80s but that has definitely not been the case for quite a while.

AlotOfReading 2y ago
> List them. I am not aware of any well defined parts of the C standard where GCC and Clang disagree in implementation. Perhaps it's not "well defined" enough for you, but one example I've been stamping out recently is whether compilers will combine subexpressions across expression boundaries. For example, if you have z = x + y; a = b * z; will the compiler optimize across the semicolon to produce an fma? GCC does it aggressively, while Clang broadly will not (though it can happen in the LLVM backend).
- Arch-TK 2y ago
  You're very right that this goes above and beyond anything the C standard specifies aside from stating that the end result should be the same as if the expressions were evaluated separately (unless you have -ffast-math enabled which makes GCC non-conformant in this regard). If the end result of the calculation differ (and remember that implementations may not always use ieee floats) then you can call it a bug in whatever compiler has that difference.
  - gpderetta 2y ago
    as it was pointed out to me recently, GCC will happily generate MADs even in standard conforming modes (in c++ at least).
    - Arch-TK 2y ago
      I have no idea how C++ defines this part of its standard but from experience it's likely that it's different in some more or less subtle way which might explain why this is okay. But in the realm of C, without -ffast-math, arithmetic operations on floats can be implemented in any way you can imagine (including having them output to a display in a room full of people with abaci and then interpreting the results of a hand-written sheet returned from said room of people) as long as the observable behaviour is as expected of the semantics. If this transformation as you describe changes the observable behaviour had it not been applied, then that's just a compiler bug. This usually means that an operation such as: double a = x / n; double b = y / n; double c = z / n; printf("%f, %f, %f\n", a, b, c); Cannot be implemented by a compiler as: double tmp = 1 / n; double a = x * tmp; double b = y * tmp; double c = z * tmp; printf("%f, %f, %f\n", a, b, c); Unless in both cases the same exact value is guaranteed to be printed for all a, b, c, and n. This is why people enable -ffast-math.

tomjakubowski 2y ago

One of the places where C and C++ differ in semantics is in their strict aliasing rules.