8 ms·

Sadly, I've lost count of how many compiler bugs I've tripped over through the years. Often it's compiler crashes -- those are usually easy to get fixed, espec

Sadly, I've lost count of how many compiler bugs I've tripped over through the years. Often it's compiler crashes -- those are usually easy to get fixed, especially when (as tends to be the case with LLVM) they are caused by assertions failing -- but I've also tripped over compiler hangs (there's a variable in the tarsnap code with an utterly bogus volatile specifier in order to avoid the problematic optimization on some versions of llvm) and outright miscompilations -- one of which has had several LLVM bug reports opened by different people over the years and remains unfixed.

empath75 9y ago
If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. For 99% of programmers, the chances that you have discovered one is small.
- blattimwind 9y ago
  The chance isn't that small, many people stumble over them and just use the first workaround SO turns up or think its actually their fault and work around it in other ways.
- topspin 9y ago
  I had some bad experiences with visual studio's compiler recently (last two years.) I was working on OpenGL code and discovered a couple different constructs that would crash the compiler. The first time I figured it was a fluke, but by the third distinct case I became rather alarmed; the code should have produced errors, not compiler failures. I concluded that MS's compiler is decidedly less robust than GCC and clang; I've seen one compiler crash from a release GCC compiler in the last 10-odd years.
  - MichaelGG 9y ago
    Yeah working on FreeSWITCH, upgrading to VS2015 and we encountered an issue with a long series of else branches. Ended up having to split and nest for the code to compile.
  - dvtv75 9y ago
    When I was in my first year of Computer Science (17 years ago), I had this CodeWarrior error that still makes me chuckle. I think I had a comment, assignment, and a System.out.println(); It wouldn't compile, had an error every single time. The tutors took a look at my code, and one-by-one gathered around until they were all there. Eventually, someone (Natalie) moved the comment below the assignment, and it worked normally. I tried putting it back above, and it wouldn't compile. Can't remember what happened if I left the moved comment in place and put another above the assignment. I found two like that - one in CodeWarrior, one in Turbo Pascal a few years before that simply returned "error 0: no error." It wasn't anything complicated in either case, just very basic stuff.
    - throwaway613834 9y ago
      Any chance the line endings were different and that was somehow messing it up?
    - nv-vn 9y ago
      Something similar happened to me a while back in Mono/C#. I think it was the order of assignments for an unused variable changed the results of the code. Something like: int x = 0; int y = 2; DoSomething(); // Didn't run with x before y I can't recall if I ever reported it or bothered looking into it, but a friend ran into a similar issue around the same time and it was really confusing, but it was resolved by changing some configuration (different compiler version or flags I think). Only other time I bumped into it was in Idris, which is to be expected frankly.
      - ethbro 9y ago
        From what I remember of a deep dive post I read on this once, the ordering type bug / no-bug situations tend to be the result of incorrect optimizations. Changing the ordering will sometimes make the code look just different enough to go down a different (not bugged) optimization path. If you ever catch them still there with a "no optimizations" flag, then that's a pretty serious bug!
    - jfultz 9y ago
- coldtea 9y ago
  That was true-er when by compilers one meant GCC or some such. Now everybody and their dog write compilers and transpilers for young and/or obscurer languages (I'd include Go and Rust in there), and with the immaturity of these environments compiler bugs are a fact of life.
  - groby_b 9y ago
    Nope. Wasn't true then, either. Found bugs in Lattice, gcc, egcs, Borland, Aztec, and probably a few more that I'm forgetting. They're never common, but "it's never the compiler" doesn't apply either. It is, however, a helpful reminder that the most likely source of problems is with the author of the code :)
    - TickleSteve 9y ago
      Care to explain the "bugs" you found?
      - groby_b 9y ago
        Obviously broken code generation, in the sense that the code provably does not behave as it should under the spec. Usually as a result of optimization gone wrong. If you're asking for actual examples - sorry, you're out of luck. The 80's and 90's are a bit too long ago for me to remember details. If you prefer to believe in the magically flawless compiler fairy, knock yourself out.
  - BellsOnSunday 9y ago
    Yep, I was going to comment that if you write your own compiler you'll find plenty of bugs, which is the same point.
- com2kid 9y ago
  In 2012 I used a C compiler where using printf to output a 64bit integer would corrupt the stack. Not that hard to stumble upon, but it took us awhile to figure out what the heck was going on.
  - TickleSteve 9y ago
    That sounds like a bug in the standard library... not a bug in the compiler.
    - cperciva 9y ago
      Not necessarily. Could be a problem with passing 64-bit values to varadic functions generally. I could definitely imagine this happening on a 32-bit platform.
      - thriftwy 9y ago
        This has bitten me on QNX. I was porting UQM for fun, and it was failing when entering a dialogue, Turns out, on QNX you can't pass short int into variadic function, which is expected behavior as far as C is concerned (you should only pass int or full size types), but it worked on every other arch so it took me a while.
    - com2kid 9y ago
      The generated assembly was garbage, so I assume it was a compiler bug. It also got fixed in later revisions, but since the compiler is shipped with the CRT... :) I don't actually recall if we were using the shipped CRT or not, I'm guessing only minimal parts of it were used, if any, since embedded projects tend to write their own subset of the needed standard library functions.
- CountHackulus 9y ago
  I worked a compiler backend for 5 years. Despite the insane amount of testing, fuzzing, standards tests, etc that we did, there were always bugs coming in, and not always in code that looked dodgy. Sometimes an optimization interacts with another in JUST the right way to cause incorrect code to get generated. Honestly, I'm surprised that I haven't run into more of them in the wild.
- bbanyc 9y ago
  I remember reading that TeX uncovered a remarkable number of bugs in Pascal compilers back in the day.
- hossbeast 9y ago
  Nothing magical about writing a compiler. The humans that make them introduce bugs, like with all software.
  - modulusshift 9y ago
    A compiler in particular is a very extreme case. Most software is used to its fullest extent by its developer, 90% of bugs are likely to be found by said developer in their normal usage. Another step out, library developers often use their work, but often build in functionality they're not as interested in by request or as a result of generalizing beyond their specific use cases. They might not be the heaviest users of that software, and so aren't as likely to find some of the bugs. Compilers are the most extreme case. Anything Turing complete is almost certain to have vast swathes of functionality which aren't used by the developer. If a compiler doesn't already have a large user base, then unless you're using it exactly like someone else has, you're almost guaranteed to find some bugs. Honestly that's true for most software, going back to the maxim "don't be the biggest user of any given software unless you're already capable of writing it yourself."
- alphaalpha101 9y ago
  I used to say similar things, and then I encountered the horror that is the Swift compiler. So many bugs. So many crashes. So many performance issues.
- gioele 9y ago
  > If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. I'm one of those that routinely find a bug in a library during the very first use of its API. Every "quick weekend project" turns into "let's learn the build system of this library and send a patch/bug report to the maintainer". Does anybody know how can I turn this annoying superpower of mine into a job that is not basic Q/A?
  - lmm 9y ago
    Might make you suited to security consulting?
  - SCHiM 9y ago
    Go into security and turn that free bugreport into big budget bug bounties ;) If you can find bugs in libraries used in IOS/Android or something, that's worth money and gives you the chance to increase security for millions (billions?) of people.
  - majewsky 9y ago
    I have a similar thing with typos. Give me a page of printed text, and there's a surprisingly high chance I will spot a typo within the first few seconds of looking at the page, no matter where the typo occurs on the page. (Might be confirmation bias, but I have been proofreading a lot of theses for my friends while in college, so it might be trained.)
  - adrianN 9y ago
    Get into an industry that values Q/A a lot. Aerospace, rail, nuclear power plants. Q/A doesn't have to be a dead-end job, career-wise.
  - ggm 9y ago
    <quote>Does anybody know how can I turn this annoying superpower of mine into a job that is not basic Q/A? </quote> What would you say, if I told you that this superpower was not basic Q/A? because basic Q/A is what the compiler is passing, all the time. The part you meant with vigour was the <b>job</b> part right? how do you make somebody want your awesome enough to pay you a living wage? It's either apple or Intel, because they are the two people financially vested in llvm.
- arghwhat 9y ago
  This is just plain wrong. It's a terrible idea to assume that other humans don't make mistakes. When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. There is no level of development that is immune. Sometimes you are to blame. Others, it might be a library. It might be the standard library, or the compiler. A faulty optimization, perhaps. Could also be the OS kernel, or even the hardware (CPU, USB controller, network card, ...). It's all chock-full of bugs. I've hit a handful of miscompilations while writing boring JavaScript web apps, some only when the JIT kicks in for extra fun. I have a handful of outstanding Linux kernel bugs, one of which cause memory corruptions, has existed at least since 2.6 and is dead simple to reproduce. I have a significant GCC performance degradation bug, triggered by calling "pthread_exit(3)" after an infinite loop. I've had what seemed to be software problems turn out to be PCIe problems. You might think that, as a developer, you're building a card-house on a solid foundation. But no, it's card-houses all the way down.
  - Cpoll 9y ago
    “It is never a compiler error” means don't waste your time blaming the compiler, first assume it's your fault. For every person who genuinely ran into a compiler bug, there are orders of magnitude more who think they did, but didn't. If you start saying "it could be a compiler bug," you're encouraging them to waste their time. > When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. I agree wholeheartedly. Saying "it is never a compiler error" doesn't preclude this; it encourages this behavior. Even thinking "it could be a compiler error" invites laziness.
    - arghwhat 9y ago
      Laziness invites efficiency. I strongly disagree with your point of view: "it is never a compiler error" not only precludes suspicion of the lower levels—voicing your suspicion of problems in lower layers will generally result in ridicule!—but it reducing critical thinking, bars people from looking into "complicated" projects, and makes them overall less efficient and skilled developers. I also disagree that encouraging a bit of wasted time is a problem. What is a few hours, or even days "wasted" learning your lesson once and for all if it greatly improves your debugging skill and efficiency? You do not learn without mistakes. "It is never a compiler error" is a detrimental mindset to have, in that it suggests a mentality where you shut your eyes for anything you did not author. After all, it is too complex, too well-tested, too well-designed, and implemented by much smarter people than you. Compiler, library, application, hardware, train, bridge, it doesn't matter. Not only does this mean that you often won't find the bug you hit, as you won't start instrumenting the faulty LargePopularLibrary—after all, it obviously can't be to blame—but it also means that you won't as much as read library|compiler|kernel|etc source code, much less do development on it, as you think it is above you, despite it by no means being some magical black art. "It could be a compiler error" invites you to consider all possibilities. Immediately blaming the compiler without reasonable evidence would, despite such a mantra, be a result of terrible debugging skills. These debugging skills should be improved through other means than intentionally teaching falsehoods, and if the subject is not an entirely lost cause, it should correct itself in much more valuable ways if a little time is "wasted" on improper debugging. Teach proper debugging techniques instead of lying to others, or yourself.
- dep_b 9y ago
  > If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. A Swift developer? Just yesterday I found myself compiling a new part of code in increments because all of the new code together wouldn't compile but adding the code and import first, compiling it before adding @UIApplicationMain would compile just fine. Exactly the same code that didn't build before. I can't imagine what I would have done if I would have trusted that this was my error because the compiler would not make mistakes. Though nothing compared to Swift 1.x, things tend to work generally and if the compiler does crash it'll crash on weird programming mistakes (like referencing type(of: self) before init() was called)
throwaway613834 9y ago
To be fair, I've also lost count of the number of times my compiler has compiled things correctly. ;)
- deleted 9y ago
  [deleted]
- neals 9y ago
  Yes, let's not anger our compilers now...
- delecti 9y ago
  Which, lets not forget, includes several times every time you load a website.
  - arghwhat 9y ago
    Please don't remind me...
revelation 9y ago
clang/llvm makes the gcc developers look like amateurs when it comes to reckless optimizations for that extra percent in the synthetic benchmark. My goto approach for when something breaks in clang but works in gcc is to disable optimization, and when I can narrow it down to a single offending function, that gets optnone slapped on it and done.
- wyldfire 9y ago
  > reckless ... is in the eye of the beholder. They exploit every corner of undefined behavior to the benefit of performance. Indeed other compilers might be "safer." Keep in mind that they also provide you with UBSan to help you detect when you're doing it wrong.
  - revelation 9y ago
    UBSan catches undefined behavior at runtime - so by definition everything it reports was not used by Clang to fold your program to a constant.
    - gpderetta 9y ago
      When the sanitizer is on, the optimizer (modulo bugs of course) does not remove the checks.
    - deleted 9y ago
      [deleted]
  - ajross 9y ago
    That argument would make more sense if they actually were faster, which they often aren't. Last I checked (and I don't keep up with this, to be fair) they still lagged gcc on most macrobenchmarks on x86.
    - davidcuddeback 9y ago
      > they still lagged gcc Isn't the "they" in this thread gcc, or did I misread something?
hyperpallium 9y ago
Yay, I've found a compiler error (and a hardware error too). Only one each, though, and it took me a while to be sure.
infradig 9y ago
Many years ago I found a bug in GCC. Reported it, it got fixed, I got thanked.
GuB-42 9y ago
I think I had only a single compiler error in my entire career that wasn't about robustness (ex: code crashing the compiler instead of producing an error). Updating the compiler fixed it. I'd rank the likelihood of an error like this : - My fault - API bug - broken environment (ex: corrupted object files) - hardware problem - OS bug - compiler bug - bug in malloc()/free() ;)

empath75 9y ago

If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. For 99% of programmers, the chances that you have discovered one is small.

blattimwind 9y ago
The chance isn't that small, many people stumble over them and just use the first workaround SO turns up or think its actually their fault and work around it in other ways.
topspin 9y ago
I had some bad experiences with visual studio's compiler recently (last two years.) I was working on OpenGL code and discovered a couple different constructs that would crash the compiler. The first time I figured it was a fluke, but by the third distinct case I became rather alarmed; the code should have produced errors, not compiler failures. I concluded that MS's compiler is decidedly less robust than GCC and clang; I've seen one compiler crash from a release GCC compiler in the last 10-odd years.
- MichaelGG 9y ago
  Yeah working on FreeSWITCH, upgrading to VS2015 and we encountered an issue with a long series of else branches. Ended up having to split and nest for the code to compile.
- dvtv75 9y ago
  When I was in my first year of Computer Science (17 years ago), I had this CodeWarrior error that still makes me chuckle. I think I had a comment, assignment, and a System.out.println(); It wouldn't compile, had an error every single time. The tutors took a look at my code, and one-by-one gathered around until they were all there. Eventually, someone (Natalie) moved the comment below the assignment, and it worked normally. I tried putting it back above, and it wouldn't compile. Can't remember what happened if I left the moved comment in place and put another above the assignment. I found two like that - one in CodeWarrior, one in Turbo Pascal a few years before that simply returned "error 0: no error." It wasn't anything complicated in either case, just very basic stuff.
  - throwaway613834 9y ago
    Any chance the line endings were different and that was somehow messing it up?
  - nv-vn 9y ago
    Something similar happened to me a while back in Mono/C#. I think it was the order of assignments for an unused variable changed the results of the code. Something like: int x = 0; int y = 2; DoSomething(); // Didn't run with x before y I can't recall if I ever reported it or bothered looking into it, but a friend ran into a similar issue around the same time and it was really confusing, but it was resolved by changing some configuration (different compiler version or flags I think). Only other time I bumped into it was in Idris, which is to be expected frankly.
    - ethbro 9y ago
      From what I remember of a deep dive post I read on this once, the ordering type bug / no-bug situations tend to be the result of incorrect optimizations. Changing the ordering will sometimes make the code look just different enough to go down a different (not bugged) optimization path. If you ever catch them still there with a "no optimizations" flag, then that's a pretty serious bug!
  - jfultz 9y ago
coldtea 9y ago
That was true-er when by compilers one meant GCC or some such. Now everybody and their dog write compilers and transpilers for young and/or obscurer languages (I'd include Go and Rust in there), and with the immaturity of these environments compiler bugs are a fact of life.
- groby_b 9y ago
  Nope. Wasn't true then, either. Found bugs in Lattice, gcc, egcs, Borland, Aztec, and probably a few more that I'm forgetting. They're never common, but "it's never the compiler" doesn't apply either. It is, however, a helpful reminder that the most likely source of problems is with the author of the code :)
  - TickleSteve 9y ago
    Care to explain the "bugs" you found?
    - groby_b 9y ago
      Obviously broken code generation, in the sense that the code provably does not behave as it should under the spec. Usually as a result of optimization gone wrong. If you're asking for actual examples - sorry, you're out of luck. The 80's and 90's are a bit too long ago for me to remember details. If you prefer to believe in the magically flawless compiler fairy, knock yourself out.
- BellsOnSunday 9y ago
  Yep, I was going to comment that if you write your own compiler you'll find plenty of bugs, which is the same point.
com2kid 9y ago
In 2012 I used a C compiler where using printf to output a 64bit integer would corrupt the stack. Not that hard to stumble upon, but it took us awhile to figure out what the heck was going on.
- TickleSteve 9y ago
  That sounds like a bug in the standard library... not a bug in the compiler.
  - cperciva 9y ago
    Not necessarily. Could be a problem with passing 64-bit values to varadic functions generally. I could definitely imagine this happening on a 32-bit platform.
    - thriftwy 9y ago
      This has bitten me on QNX. I was porting UQM for fun, and it was failing when entering a dialogue, Turns out, on QNX you can't pass short int into variadic function, which is expected behavior as far as C is concerned (you should only pass int or full size types), but it worked on every other arch so it took me a while.
  - com2kid 9y ago
    The generated assembly was garbage, so I assume it was a compiler bug. It also got fixed in later revisions, but since the compiler is shipped with the CRT... :) I don't actually recall if we were using the shipped CRT or not, I'm guessing only minimal parts of it were used, if any, since embedded projects tend to write their own subset of the needed standard library functions.
CountHackulus 9y ago
I worked a compiler backend for 5 years. Despite the insane amount of testing, fuzzing, standards tests, etc that we did, there were always bugs coming in, and not always in code that looked dodgy. Sometimes an optimization interacts with another in JUST the right way to cause incorrect code to get generated. Honestly, I'm surprised that I haven't run into more of them in the wild.
bbanyc 9y ago
I remember reading that TeX uncovered a remarkable number of bugs in Pascal compilers back in the day.
hossbeast 9y ago
Nothing magical about writing a compiler. The humans that make them introduce bugs, like with all software.
- modulusshift 9y ago
  A compiler in particular is a very extreme case. Most software is used to its fullest extent by its developer, 90% of bugs are likely to be found by said developer in their normal usage. Another step out, library developers often use their work, but often build in functionality they're not as interested in by request or as a result of generalizing beyond their specific use cases. They might not be the heaviest users of that software, and so aren't as likely to find some of the bugs. Compilers are the most extreme case. Anything Turing complete is almost certain to have vast swathes of functionality which aren't used by the developer. If a compiler doesn't already have a large user base, then unless you're using it exactly like someone else has, you're almost guaranteed to find some bugs. Honestly that's true for most software, going back to the maxim "don't be the biggest user of any given software unless you're already capable of writing it yourself."
alphaalpha101 9y ago
I used to say similar things, and then I encountered the horror that is the Swift compiler. So many bugs. So many crashes. So many performance issues.
gioele 9y ago
> If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. I'm one of those that routinely find a bug in a library during the very first use of its API. Every "quick weekend project" turns into "let's learn the build system of this library and send a patch/bug report to the maintainer". Does anybody know how can I turn this annoying superpower of mine into a job that is not basic Q/A?
- lmm 9y ago
  Might make you suited to security consulting?
- SCHiM 9y ago
  Go into security and turn that free bugreport into big budget bug bounties ;) If you can find bugs in libraries used in IOS/Android or something, that's worth money and gives you the chance to increase security for millions (billions?) of people.
- majewsky 9y ago
  I have a similar thing with typos. Give me a page of printed text, and there's a surprisingly high chance I will spot a typo within the first few seconds of looking at the page, no matter where the typo occurs on the page. (Might be confirmation bias, but I have been proofreading a lot of theses for my friends while in college, so it might be trained.)
- adrianN 9y ago
  Get into an industry that values Q/A a lot. Aerospace, rail, nuclear power plants. Q/A doesn't have to be a dead-end job, career-wise.
- ggm 9y ago
  <quote>Does anybody know how can I turn this annoying superpower of mine into a job that is not basic Q/A? </quote> What would you say, if I told you that this superpower was not basic Q/A? because basic Q/A is what the compiler is passing, all the time. The part you meant with vigour was the <b>job</b> part right? how do you make somebody want your awesome enough to pay you a living wage? It's either apple or Intel, because they are the two people financially vested in llvm.
arghwhat 9y ago
This is just plain wrong. It's a terrible idea to assume that other humans don't make mistakes. When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. There is no level of development that is immune. Sometimes you are to blame. Others, it might be a library. It might be the standard library, or the compiler. A faulty optimization, perhaps. Could also be the OS kernel, or even the hardware (CPU, USB controller, network card, ...). It's all chock-full of bugs. I've hit a handful of miscompilations while writing boring JavaScript web apps, some only when the JIT kicks in for extra fun. I have a handful of outstanding Linux kernel bugs, one of which cause memory corruptions, has existed at least since 2.6 and is dead simple to reproduce. I have a significant GCC performance degradation bug, triggered by calling "pthread_exit(3)" after an infinite loop. I've had what seemed to be software problems turn out to be PCIe problems. You might think that, as a developer, you're building a card-house on a solid foundation. But no, it's card-houses all the way down.
- Cpoll 9y ago
  “It is never a compiler error” means don't waste your time blaming the compiler, first assume it's your fault. For every person who genuinely ran into a compiler bug, there are orders of magnitude more who think they did, but didn't. If you start saying "it could be a compiler bug," you're encouraging them to waste their time. > When encountering a bug, start at the top, and work your way down when you conclude that the current level is correct. I agree wholeheartedly. Saying "it is never a compiler error" doesn't preclude this; it encourages this behavior. Even thinking "it could be a compiler error" invites laziness.
  - arghwhat 9y ago
    Laziness invites efficiency. I strongly disagree with your point of view: "it is never a compiler error" not only precludes suspicion of the lower levels—voicing your suspicion of problems in lower layers will generally result in ridicule!—but it reducing critical thinking, bars people from looking into "complicated" projects, and makes them overall less efficient and skilled developers. I also disagree that encouraging a bit of wasted time is a problem. What is a few hours, or even days "wasted" learning your lesson once and for all if it greatly improves your debugging skill and efficiency? You do not learn without mistakes. "It is never a compiler error" is a detrimental mindset to have, in that it suggests a mentality where you shut your eyes for anything you did not author. After all, it is too complex, too well-tested, too well-designed, and implemented by much smarter people than you. Compiler, library, application, hardware, train, bridge, it doesn't matter. Not only does this mean that you often won't find the bug you hit, as you won't start instrumenting the faulty LargePopularLibrary—after all, it obviously can't be to blame—but it also means that you won't as much as read library|compiler|kernel|etc source code, much less do development on it, as you think it is above you, despite it by no means being some magical black art. "It could be a compiler error" invites you to consider all possibilities. Immediately blaming the compiler without reasonable evidence would, despite such a mantra, be a result of terrible debugging skills. These debugging skills should be improved through other means than intentionally teaching falsehoods, and if the subject is not an entirely lost cause, it should correct itself in much more valuable ways if a little time is "wasted" on improper debugging. Teach proper debugging techniques instead of lying to others, or yourself.
dep_b 9y ago
> If you’re the kind of programmer who is likely to find compiler errors, you probably know who you are. A Swift developer? Just yesterday I found myself compiling a new part of code in increments because all of the new code together wouldn't compile but adding the code and import first, compiling it before adding @UIApplicationMain would compile just fine. Exactly the same code that didn't build before. I can't imagine what I would have done if I would have trusted that this was my error because the compiler would not make mistakes. Though nothing compared to Swift 1.x, things tend to work generally and if the compiler does crash it'll crash on weird programming mistakes (like referencing type(of: self) before init() was called)

throwaway613834 9y ago

To be fair, I've also lost count of the number of times my compiler has compiled things correctly. ;)

deleted 9y ago
[deleted]
neals 9y ago
Yes, let's not anger our compilers now...
delecti 9y ago
Which, lets not forget, includes several times every time you load a website.
- arghwhat 9y ago
  Please don't remind me...

revelation 9y ago

clang/llvm makes the gcc developers look like amateurs when it comes to reckless optimizations for that extra percent in the synthetic benchmark. My goto approach for when something breaks in clang but works in gcc is to disable optimization, and when I can narrow it down to a single offending function, that gets optnone slapped on it and done.

wyldfire 9y ago
> reckless ... is in the eye of the beholder. They exploit every corner of undefined behavior to the benefit of performance. Indeed other compilers might be "safer." Keep in mind that they also provide you with UBSan to help you detect when you're doing it wrong.
- revelation 9y ago
  UBSan catches undefined behavior at runtime - so by definition everything it reports was not used by Clang to fold your program to a constant.
  - gpderetta 9y ago
    When the sanitizer is on, the optimizer (modulo bugs of course) does not remove the checks.
  - deleted 9y ago
    [deleted]
- ajross 9y ago
  That argument would make more sense if they actually were faster, which they often aren't. Last I checked (and I don't keep up with this, to be fair) they still lagged gcc on most macrobenchmarks on x86.
  - davidcuddeback 9y ago
    > they still lagged gcc Isn't the "they" in this thread gcc, or did I misread something?

hyperpallium 9y ago

Yay, I've found a compiler error (and a hardware error too). Only one each, though, and it took me a while to be sure.

infradig 9y ago

Many years ago I found a bug in GCC. Reported it, it got fixed, I got thanked.

GuB-42 9y ago

I think I had only a single compiler error in my entire career that wasn't about robustness (ex: code crashing the compiler instead of producing an error). Updating the compiler fixed it. I'd rank the likelihood of an error like this : - My fault - API bug - broken environment (ex: corrupted object files) - hardware problem - OS bug - compiler bug - bug in malloc()/free() ;)