6 ms·

I'm a compiler writer. I'm not actually unsympathetic to these points, and agree that compilers intended for practical use had better have strong justification

I'm a compiler writer. I'm not actually unsympathetic to these points, and agree that compilers intended for practical use had better have strong justification for surprising behavior. But the pervasively nasty tone of the paper is not going to make many friends among the people whose work the authors are trying to influence.

anon4 11y ago
You reap what you sow. GCC authors have already shown they don't want to be in the "friends" camp anyway, so the best possible outcome at this point is a fork of GCC and/or Clang that actually compiles programs properly.
WalterBright 11y ago
I agree about the unpleasant tone of the paper, putting "facts" and "optimizations" in quotes, implying they are not real, and talking about "claims" of GCC maintainers, and cracks about psychic powers. But there is a good underlying point to the paper, and one I tend to agree with - a compiler's behavior should give considerable weight to how the language is used more than taking a literal view of what the words mean in the spec. Taking things to an absurd extreme to make the point, "undefined behavior" implies that a compiler writer can insert code to reformat the hard disk if it encountered such code. Granted, the point of a spec is to define things so that compiler writers don't have to divine intent, but perfection is never attained and hence compiler writers have to use their judgment. I know in my compiler work, I have backed out some optimizations that were allowed by the spec, but broke too many programs. The inconsequential speed improvement was just not worth it.
- DannyBee 11y ago
  "a compiler's behavior should give considerable weight to how the language is used more than taking a literal view of what the words mean in the spec." This is generally true, but the problem in this case is the committee history of a lot of what is being complained about shows it was added specifically to let compilers reason the way they do. The committee didn't sit down and say "hey, this should be undefined, because it sucked". Instead, what happened is committee members and compiler writers sat down and said the compiler guys said "if you make this undefined, we can optimize this thing over here better", and the committee said "great, sounds awesome". Complaining that the compiler writers then go and do that is misguided :) (This covers most of the specific examples given, BTW. There are other examples where he dismissively claims that what should happen is obvious.) The whole thing is like complaining that people follow the law, instead of the spirit of the law.
  - tytso 11y ago
    The question I have is whether committee members are sufficiently representative of programmers in the trenches, and whether committee members are sufficiently informed about the impact of their saying, "great, sounds awesome".
    - DannyBee 11y ago
      Sometimes yes, sometimes no. But in some sense, it doesn't matter. They are the ones defining C. If people don't like it, they should create Cgood or whatever. This has been tried before, and it has never caught on. I'm not worried. If the programmers in the trenches really hate it so much, C will eventually die off in favor of something better :)
      - aidenn0 11y ago
        To be fair Cgood doesn't catch on because no compiler vendors implement it, and the C standards committe is at least somewhat beholden to the compiler vendors because if the compiler vendors en-masse decided not to implement their standard, then the standard isn't worth the paper it's printed on.
        DannyBee 11y ago
        This is entirely true, but at the same time: Compiler vendors are people, and in fact, if you don't like that set of people, there are plenty of vendors who have forks :) IE if you don't like gcc 4.8's treatment of behavior, it's not like there aren't 50 different arm forks from different vendors you can use, with or without their SOC's. Yet none of these vendors have apparently heard enough from customers that they have made what are pretty simple patches.
        WalterBright 11y ago
        It's really, really hard to sell someone on a non-standard implementation of a popular language like C. For example, I've had customers beg me to add an extension to C. I implement it, and present it to them. They refuse to use it - because then their code would be dependent on a non-Standard feature. The solution (for me, anyway) was to create an entirely new language. The changes that nobody wanted in C (not because they were bad, but because they were non-Standard) found plenty of traction and users in D.
- tytso 11y ago
  It may be unpleasant, but the reality is that many programmers do feel that way. I can say that as a kernel programmer, I approach using a new version of gcc with a particular version of dread. What sort of random bugs that might end up causing kernel crashes or data corruption will arise when I try using a new compiler? As a result, I'm quite sympathetic to the attitude of "any sufficiently advanced compiler is indistinguishable from a malicious adversary"....
  - eru 11y ago
    Just use a more defined language than C..
    - conceit 11y ago
      Optimally a compiler's version of a language is better defined simply by it's definitions. It's just problematic if the behavior is changed between versions, eg. for the sake of optimizations. It's also bad if undefined behavior is expected to be reliable where the original implementation wasn't intended to be meaningful in the first place. If those two cases are hard to tell apart, the process of announcing this is at fault, I guess, e.g. the error messages and warnings, the documentation, the info hidden in discussions on the mailinglists or in bug reports, but the gcc docs seem fairly extensive and I can't claim to have read it completely or the c standard.
    - ScottBurson 11y ago
      Yes. I think, if I had to do embedded work, I would use Ada.
      - eru 11y ago
        Or even use an explicit C-like dialect that defines more things, if you like the syntax.
      - klibertp 11y ago
        I immediately thought about the same language. It's clean, safe, fast and explicit, even if a bit verbose. With a quite nice compiler, last time I checked (some 10 years ago), and without "undefined behaviour".
- bluecalm 11y ago
  The problem is that many programmers who are actually competent and care about speed welcome each and every new GCC release with joy checking the change-log for optimizer improvements. I mean, people who actually check the docs instead of ranting about how int overflow doesn't behave according to some wishful thinking. >>The inconsequential speed improvement was just not worth it. Yeah, but the author if taking about very significant speed improvements (often bigger than 5%) which only brake really bad code (relying on behavior of int overflow).
  - nkurz 11y ago
    Is your positive experience with C, or C++? I think a lot of the friction is that the two languages often share a compiler but not a philosophy. Modern templated C++ depends heavily on the compiler's ability to optimize out redundant code, while many C programmers still want to more of a WYSIWYG compiler. I often get the feeling that many people involved with GCC would be happier if they could drop C compatibility and just work on a C++ compiler. Ertl's work is at a low enough level where he knows in advance what the assembly of the optimized loops should look like. For example, here's a big improvement to the Python interpreter that's based on his work: https://bugs.python.org/issue4753 https://bugs.python.org/issue4753. What he, and I, and some small but significant number of others, wish for is that there was a way to write C that will reliably produce the output we envision. The chances that an optimizer will make better code than this is low, whereas the chance that attempts to optimize the code will produce worse code is very high. I'd be interested to see an "out of sample" longitudinal look at performance of some optimized C code with different versions of GCC. That is, ignore the code used in the standard benchmarks, since the optimization strategies have been consciously chosen to do well on that code, and instead look at code that was written for high performance with older compilers but hasn't yet been tested with current compilers. I don't know for sure what it would show, but I'm guessing it would be more of a mixed bag rather than a monotonic improvement.
    - bluecalm 11y ago
      >>Is your positive experience with C, or C++? It's very positive. Python used to be my favorite programming language, now it's C. I don't code anything in C++ so I don't know, the experience was very negative when I've learnt some of it long time ago but maybe it would be different today. >>What he, and I, and some small but significant number of others, wish for is that there was a way to write C that will reliably produce the output we envision. The chances that an optimizer will make better code than this is low, whereas the chance that attempts to optimize the code will produce worse code is very high. Ok, I can definitely see the point. Still it irks me when something as simple as integer overflow is the reason source of rants about UB. I do agree that it would be nice to have some universal way to drop to assembly. I am in probably rare position that I write code which sells because of performance but I am not that good with assembly (the reason is that I am relatively new and work in a niche). That means that optimizer improvements are more important for me than "stick to what is written even if you don't understand it" kind of compiler. >>. I don't know for sure what it would show, but I'm guessing it would be more of a mixed bag rather than a monotonic improvement. It could be because programmers fit what they do to the compiler. My approach is to just test a lot of things and leave what sticks so my code is naturally a better fit to a compiler I work with. Still, updating my old GCC to 4.8 was a huge boost in speed and updating to 5.3 recently gave me additional free 4%-5% while compiling faster and offering some new warnings.
- Dylan16807 11y ago
  > putting "facts" and "optimizations" in quotes "facts" absolutely should be in quotes there. He's describing assertions like "x cannot be null", something that is inferred from the code and treated as fact but turns out not to be true at runtime.
- iherbig 11y ago
  As far as I'm aware, the author was using optimizations in quotes ("optimizations") to parallel the previously defined C* and "C" distinctions. Hence why section 2.1 is called 'Optimization* and "Optimization".' He's not suggesting they are not real optimizations, but that they are a class of optimizations which target the "C" subset rather than the C* superset. At least, that was my understanding of it. People seem to be reading into the quotes as indicative of tone rather than notation, so I wanted to put a different perspective out there.
  - AntonErtl 11y ago
    Thank you for the interest in this paper. You read one intention of the quotes right. But they are also intended to be scare quotes; if the result of an "optimization" is equivalent to the behaviour intended by the programmer that also worked with earlier versions of the compiler, it's a real optimization, if not, it's miscompilation. E.g., "optimizing" a bounded loop into an endless loop is not a real optimization.
- yxhuvud 11y ago
  > I know in my compiler work, I have backed out some optimizations that were allowed by the spec, but broke too many programs. The inconsequential speed improvement was just not worth it. Then perhaps those cases should be reported to the spec commitee to perhaps make the optimization not allowed?
  - pjmlp 11y ago
    They will never care about it. The very reason C is full of UB is that no compiler vendor wanted to change their compiler dialect when ANSI C was being defined. So every little detail that deviated from the original C compiler was marked as UB.
marssaxman 11y ago
I can't currently say that I am a compiler writer, since I'm working on static analysis tools, but I have been a compiler writer for more of my career than I have been anything else, and I was thoroughly amused by the tone of the paper. It's not particularly professional, and it's not likely to change minds among the people he is excoriating, but I don't think that's the point. Instead, I think he's trying to shift the "Overton window", to embolden people uncomfortable with the status quo, so that they can argue for what they want instead of accepting the opinions of compiler writers as some kind of unchangeable holy writ.
- Gibbon1 11y ago
  I think you should consider the perspective of programmers who have to write code where all the side effects aren't hidden behind the operating systems API calls.
  - marssaxman 11y ago
    I would be happy to, but I don't know what you have in mind by that - explain?

anon4 11y ago

You reap what you sow. GCC authors have already shown they don't want to be in the "friends" camp anyway, so the best possible outcome at this point is a fork of GCC and/or Clang that actually compiles programs properly.

WalterBright 11y ago

I agree about the unpleasant tone of the paper, putting "facts" and "optimizations" in quotes, implying they are not real, and talking about "claims" of GCC maintainers, and cracks about psychic powers. But there is a good underlying point to the paper, and one I tend to agree with - a compiler's behavior should give considerable weight to how the language is used more than taking a literal view of what the words mean in the spec. Taking things to an absurd extreme to make the point, "undefined behavior" implies that a compiler writer can insert code to reformat the hard disk if it encountered such code. Granted, the point of a spec is to define things so that compiler writers don't have to divine intent, but perfection is never attained and hence compiler writers have to use their judgment. I know in my compiler work, I have backed out some optimizations that were allowed by the spec, but broke too many programs. The inconsequential speed improvement was just not worth it.

DannyBee 11y ago
"a compiler's behavior should give considerable weight to how the language is used more than taking a literal view of what the words mean in the spec." This is generally true, but the problem in this case is the committee history of a lot of what is being complained about shows it was added specifically to let compilers reason the way they do. The committee didn't sit down and say "hey, this should be undefined, because it sucked". Instead, what happened is committee members and compiler writers sat down and said the compiler guys said "if you make this undefined, we can optimize this thing over here better", and the committee said "great, sounds awesome". Complaining that the compiler writers then go and do that is misguided :) (This covers most of the specific examples given, BTW. There are other examples where he dismissively claims that what should happen is obvious.) The whole thing is like complaining that people follow the law, instead of the spirit of the law.
- tytso 11y ago
  The question I have is whether committee members are sufficiently representative of programmers in the trenches, and whether committee members are sufficiently informed about the impact of their saying, "great, sounds awesome".
  - DannyBee 11y ago
    Sometimes yes, sometimes no. But in some sense, it doesn't matter. They are the ones defining C. If people don't like it, they should create Cgood or whatever. This has been tried before, and it has never caught on. I'm not worried. If the programmers in the trenches really hate it so much, C will eventually die off in favor of something better :)
    - aidenn0 11y ago
      To be fair Cgood doesn't catch on because no compiler vendors implement it, and the C standards committe is at least somewhat beholden to the compiler vendors because if the compiler vendors en-masse decided not to implement their standard, then the standard isn't worth the paper it's printed on.
      - DannyBee 11y ago
        This is entirely true, but at the same time: Compiler vendors are people, and in fact, if you don't like that set of people, there are plenty of vendors who have forks :) IE if you don't like gcc 4.8's treatment of behavior, it's not like there aren't 50 different arm forks from different vendors you can use, with or without their SOC's. Yet none of these vendors have apparently heard enough from customers that they have made what are pretty simple patches.
        WalterBright 11y ago
        It's really, really hard to sell someone on a non-standard implementation of a popular language like C. For example, I've had customers beg me to add an extension to C. I implement it, and present it to them. They refuse to use it - because then their code would be dependent on a non-Standard feature. The solution (for me, anyway) was to create an entirely new language. The changes that nobody wanted in C (not because they were bad, but because they were non-Standard) found plenty of traction and users in D.
tytso 11y ago
It may be unpleasant, but the reality is that many programmers do feel that way. I can say that as a kernel programmer, I approach using a new version of gcc with a particular version of dread. What sort of random bugs that might end up causing kernel crashes or data corruption will arise when I try using a new compiler? As a result, I'm quite sympathetic to the attitude of "any sufficiently advanced compiler is indistinguishable from a malicious adversary"....
- eru 11y ago
  Just use a more defined language than C..
  - conceit 11y ago
    Optimally a compiler's version of a language is better defined simply by it's definitions. It's just problematic if the behavior is changed between versions, eg. for the sake of optimizations. It's also bad if undefined behavior is expected to be reliable where the original implementation wasn't intended to be meaningful in the first place. If those two cases are hard to tell apart, the process of announcing this is at fault, I guess, e.g. the error messages and warnings, the documentation, the info hidden in discussions on the mailinglists or in bug reports, but the gcc docs seem fairly extensive and I can't claim to have read it completely or the c standard.
  - ScottBurson 11y ago
    Yes. I think, if I had to do embedded work, I would use Ada.
    - eru 11y ago
      Or even use an explicit C-like dialect that defines more things, if you like the syntax.
    - klibertp 11y ago
      I immediately thought about the same language. It's clean, safe, fast and explicit, even if a bit verbose. With a quite nice compiler, last time I checked (some 10 years ago), and without "undefined behaviour".
bluecalm 11y ago
The problem is that many programmers who are actually competent and care about speed welcome each and every new GCC release with joy checking the change-log for optimizer improvements. I mean, people who actually check the docs instead of ranting about how int overflow doesn't behave according to some wishful thinking. >>The inconsequential speed improvement was just not worth it. Yeah, but the author if taking about very significant speed improvements (often bigger than 5%) which only brake really bad code (relying on behavior of int overflow).
- nkurz 11y ago
  Is your positive experience with C, or C++? I think a lot of the friction is that the two languages often share a compiler but not a philosophy. Modern templated C++ depends heavily on the compiler's ability to optimize out redundant code, while many C programmers still want to more of a WYSIWYG compiler. I often get the feeling that many people involved with GCC would be happier if they could drop C compatibility and just work on a C++ compiler. Ertl's work is at a low enough level where he knows in advance what the assembly of the optimized loops should look like. For example, here's a big improvement to the Python interpreter that's based on his work: https://bugs.python.org/issue4753 https://bugs.python.org/issue4753. What he, and I, and some small but significant number of others, wish for is that there was a way to write C that will reliably produce the output we envision. The chances that an optimizer will make better code than this is low, whereas the chance that attempts to optimize the code will produce worse code is very high. I'd be interested to see an "out of sample" longitudinal look at performance of some optimized C code with different versions of GCC. That is, ignore the code used in the standard benchmarks, since the optimization strategies have been consciously chosen to do well on that code, and instead look at code that was written for high performance with older compilers but hasn't yet been tested with current compilers. I don't know for sure what it would show, but I'm guessing it would be more of a mixed bag rather than a monotonic improvement.
  - bluecalm 11y ago
    >>Is your positive experience with C, or C++? It's very positive. Python used to be my favorite programming language, now it's C. I don't code anything in C++ so I don't know, the experience was very negative when I've learnt some of it long time ago but maybe it would be different today. >>What he, and I, and some small but significant number of others, wish for is that there was a way to write C that will reliably produce the output we envision. The chances that an optimizer will make better code than this is low, whereas the chance that attempts to optimize the code will produce worse code is very high. Ok, I can definitely see the point. Still it irks me when something as simple as integer overflow is the reason source of rants about UB. I do agree that it would be nice to have some universal way to drop to assembly. I am in probably rare position that I write code which sells because of performance but I am not that good with assembly (the reason is that I am relatively new and work in a niche). That means that optimizer improvements are more important for me than "stick to what is written even if you don't understand it" kind of compiler. >>. I don't know for sure what it would show, but I'm guessing it would be more of a mixed bag rather than a monotonic improvement. It could be because programmers fit what they do to the compiler. My approach is to just test a lot of things and leave what sticks so my code is naturally a better fit to a compiler I work with. Still, updating my old GCC to 4.8 was a huge boost in speed and updating to 5.3 recently gave me additional free 4%-5% while compiling faster and offering some new warnings.
Dylan16807 11y ago
> putting "facts" and "optimizations" in quotes "facts" absolutely should be in quotes there. He's describing assertions like "x cannot be null", something that is inferred from the code and treated as fact but turns out not to be true at runtime.
iherbig 11y ago
As far as I'm aware, the author was using optimizations in quotes ("optimizations") to parallel the previously defined C* and "C" distinctions. Hence why section 2.1 is called 'Optimization* and "Optimization".' He's not suggesting they are not real optimizations, but that they are a class of optimizations which target the "C" subset rather than the C* superset. At least, that was my understanding of it. People seem to be reading into the quotes as indicative of tone rather than notation, so I wanted to put a different perspective out there.
- AntonErtl 11y ago
  Thank you for the interest in this paper. You read one intention of the quotes right. But they are also intended to be scare quotes; if the result of an "optimization" is equivalent to the behaviour intended by the programmer that also worked with earlier versions of the compiler, it's a real optimization, if not, it's miscompilation. E.g., "optimizing" a bounded loop into an endless loop is not a real optimization.
yxhuvud 11y ago
> I know in my compiler work, I have backed out some optimizations that were allowed by the spec, but broke too many programs. The inconsequential speed improvement was just not worth it. Then perhaps those cases should be reported to the spec commitee to perhaps make the optimization not allowed?
- pjmlp 11y ago
  They will never care about it. The very reason C is full of UB is that no compiler vendor wanted to change their compiler dialect when ANSI C was being defined. So every little detail that deviated from the original C compiler was marked as UB.

marssaxman 11y ago

I can't currently say that I am a compiler writer, since I'm working on static analysis tools, but I have been a compiler writer for more of my career than I have been anything else, and I was thoroughly amused by the tone of the paper. It's not particularly professional, and it's not likely to change minds among the people he is excoriating, but I don't think that's the point. Instead, I think he's trying to shift the "Overton window", to embolden people uncomfortable with the status quo, so that they can argue for what they want instead of accepting the opinions of compiler writers as some kind of unchangeable holy writ.

Gibbon1 11y ago
I think you should consider the perspective of programmers who have to write code where all the side effects aren't hidden behind the operating systems API calls.
- marssaxman 11y ago
  I would be happy to, but I don't know what you have in mind by that - explain?