Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Bug Linux

Linus Torvalds: "GCC 4.9.0 Seems To Be Terminally Broken" 739

hypnosec (2231454) writes to point out a pointed critique from Linus Torvalds of GCC 4.9.0. after a random panic was discovered in a load balance function in Linux 3.16-rc6. in an email to the Linux kernel mailing list outlining two separate but possibly related bugs, Linus describes the compiler as "terminally broken," and worse ("pure and utter sh*t," only with no asterisk). A slice: "Lookie here, your compiler does some absolutely insane things with the spilling, including spilling a *constant*. For chrissake, that compiler shouldn't have been allowed to graduate from kindergarten. We're talking "sloth that was dropped on the head as a baby" level retardation levels here .... Anyway, this is not a kernel bug. This is your compiler creating completely broken code. We may need to add a warning to make sure nobody compiles with gcc-4.9.0, and the Debian people should probably downgrate their shiny new compiler."
This discussion has been archived. No new comments can be posted.

Linus Torvalds: "GCC 4.9.0 Seems To Be Terminally Broken"

Comments Filter:
  • by serviscope_minor ( 664417 ) on Sunday July 27, 2014 @02:56PM (#47544527) Journal

    Oh gosh a compiler bug! The world is going to end and GCC is terminally broken for ever and ever and ever. Life happens, and occasionally that includes compiler bugs. I've seen fewer bugs in GCC than any other production compiler ever.

    Anyway, it seems like GCC is implementing a very obscure compiler option incorrectly in some circumstances which causes a crash.

    But of course this is cue for lamentations of how awful and braindead GCC is and so much drama.

    End result, the GCC people will fix this bug in short order (what are GCC point releases for anyway), and distributers will probably have a patch package out for 4.9.0 before 4.9.1 ships (what are distributors for anyway?) and the world will keep turning and GCC will go back from being the buggy broken braindead piece of shit to yet again being the most solid production compiler in existence.

    It's a little ironic that the he's so quick to attack the GCC people. The success of Linux is 100% built off the success of GCC. There have been no other credible compilers for Linux throughout the majority of its existence and without GCC being bulletproof, Linux would never have been solid.

  • The reddit thread... (Score:0, Interesting)

    by Anonymous Coward on Sunday July 27, 2014 @02:58PM (#47544537)

    ...which has been going a lot longer, has good discussion. The problem occurs when an uncommon combination of flags is selected in specific versions. Most people don't have to worry about this too much.

  • by serviscope_minor ( 664417 ) on Sunday July 27, 2014 @03:31PM (#47544749) Journal

    Claiming the GCC crew will 'fix this bug in short order' is like claiming Obama is leading the charge in transparent government.

    Care to take a wager that it will be fixed in 4.9.1?

    GCC has never been a solid production compiler.

    Utter crap, bordering on an outright lie.

    The list of systems I've developed on is something like: PCs, Sun, SGI, HP, AIX, PICs, 8051, Blackfin, ARM, AVR and probably a bunch I've forgotten about. I've used very many compilers over the years. There has not been one that can match GCC in solidity and general lack of bugs.

    Not. A. Single. One.

    But apparently "production compiler" in your world means something completely different.

    You have that pretty much backwards. Without Linux, GCC wouldn't matter to anyone. Linux can be built with other compilers with a little effort, ask Intel about it.

    As far as I know, it's been GCC, Intel (which is useless for Linux's most popular platforms) and TCC. I don't know of anyone who actually uses a non GCC compiled kernel.

    You're pretty clueless. Intel would beg to differ. No one that matters compiles high performance code on GCC, they use the Intel compiler.

    Ah no TRUE scotsman would use GCC. Got it.

  • by Bing Tsher E ( 943915 ) on Sunday July 27, 2014 @04:15PM (#47545049) Journal

    Yes. Choice is nice. That's why I've migrated away from all of Apple's 'flagship' products, which are proprietary closed off dead ends.

  • by bk2204 ( 310841 ) <sandals@crustytoothpaste.net> on Sunday July 27, 2014 @05:00PM (#47545401) Homepage

    LLVM has improved a lot, but in CPU-bound workloads such as cryptography, GCC still outperforms it by 15% or more.

  • "all proceeds smoothly."

    Until you submit a bug report about how every kernel can be hardlocked by an elementary school student and post the exact five steps it takes to do so.

    "Oh, the kernel is supposed to do that."

    No it isn't, Linus.

  • by bradgoodman ( 964302 ) on Sunday July 27, 2014 @08:01PM (#47546499) Homepage
    I've been doing Linux development for about 15 years - including lots of kernel work. I never have, nor ever would posted anything to the kernel mailing lists. With a few exceptions - like when I can hand it off to someone else or go through a third-party - is rather have one of my patches die - than to submit it. Reason? I've seen this kind of attitude and "abuse" and - quite frankly - would never want to subject myself to this kind of abuse should anything I say or submit be erroneous and have to tolerate listening to how "retarded" I or my work is. Personal feelings aside - I wouldn't want such very public commentary about me or my work living in such a perminant and searchable archive - say by some future employeer. I wonder if I'm alone. I wonder if others have the same attitude. I wonder if some of the actual smartest people in the world (not me) might have done some great work - but would be too shy to ever let themselves be noticed.
  • by jpellino ( 202698 ) on Monday July 28, 2014 @12:00AM (#47547419)
    Actually, "in the engineering room" he sang a different tune: https://gcc.gnu.org/bugzilla/s... [gnu.org]

1 + 1 = 3, for large values of 1.

Working...