Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

GCC 4.9 To See Significant Upgrades In 2014

Soulskill posted about a year ago | from the it's-almost-2014 dept.

Programming 191

noahfecks writes "It seems that the GCC developers are taking steps to roll out significant improvements after CLANG became more competitive. 'Among the highlights to look forward to right now with GCC 4.9 are: The Undefined Behavior Sanitizer has been ported to GCC; Ada and Fortran have seen upgrades; Improved C++14 support; RX100, RX200, and RX600 processor support; and Intel Silvermont hardware support.'"

Sorry! There are no comments related to the filter you selected.

4.8.2 is not even 2 weeks old (1, Interesting)

SpaceLifeForm (228190) | about a year ago | (#45249651)

Perhaps it should be banged on a bit before worrying about 4.9.x as it takes a while before everyone starts using the bleeding edge gcc.

Re:4.8.2 is not even 2 weeks old (4, Informative)

Anonymous Coward | about a year ago | (#45249665)

No. C++ in particular has resumed the rapid evolution it enjoyed long ago and GCC needs to keep up.

Re:4.8.2 is not even 2 weeks old (3, Interesting)

Anonymous Coward | about a year ago | (#45250195)

No. C++ in particular has resumed it's crazy-ass changes that makes code from two years ago look obsolete

FYFY. C++ will be the Fortran of our generation... twenty years from now everyone will be laughed at for touching C++, but it will have all of these nice libraries....

Re:4.8.2 is not even 2 weeks old (0)

Anonymous Coward | about a year ago | (#45250305)

Yeah, because as we all know java is so much better....

I will not utter it here (5, Funny)

Hognoxious (631665) | about a year ago | (#45250317)

If you're trying to imply that Java is the new Fortran you couldn't be more wrong.

It's the new C080L.

Haskell (0)

smitty_one_each (243267) | about a year ago | (#45250503)

Will devour you all.

Re:I will not utter it here (0)

Anonymous Coward | about a year ago | (#45252387)

No, actually I wasn't, even though in retrospect I realize it could be read that way. I was trying to say that the eventual future ridicule of C/C++ would be better directed against Java.

Of course there's always the possibility of a programmers version of Simon Wiesenthal who could track down those responsible for Java and bring them to justice.

Re:I will not utter it here (1)

phantomfive (622387) | about a year ago | (#45252455)

Modded funny, but what you say is true.

Re:4.8.2 is not even 2 weeks old (-1)

girlintraining (1395911) | about a year ago | (#45249771)

Perhaps it should be banged on a bit before worrying about 4.9.x as it takes a while before everyone starts using the bleeding edge gcc.

Why? Compilers are pretty simple; Difficult for a lot of people to conceptualize, yes, but for those who can make that leap of understanding, not terribly difficult to design. What reason do you have to suspect instability in the 4.9 branch?

Re:4.8.2 is not even 2 weeks old (4, Informative)

Anonymous Coward | about a year ago | (#45249799)

Because since 4.6, gcc has severe stability problems? The only version that can compile more complicated C++11 reliably is 4.7.3 -- earlier versions (4.6.x in particular) have a strong tendency to ICE (including segfaults). And 4.8.0 has a performance regression where some files compile multiple hours instead of a few minutes. I have to check with 4.8.2 (I really really hope it works, because clang -- and especially libc++ -- is not as universally available yet).

Re: 4.8.2 is not even 2 weeks old (4, Interesting)

loufoque (1400831) | about a year ago | (#45250109)

I thought I was the only one with the performance problems. No one seems to care about my bug reports. Most of the overhead seems to come from the new macro tracing feature, by the way.

For C++ programming you'll need GCC 4.8 anyway because there is no way to get a complete template trace with 4.6 or 4.7. I don't understand what thet were thinking when they decided to skip arbitrary instantiation contexts in the trace with no ability to not skip them.

Re:4.8.2 is not even 2 weeks old (1)

Anonymous Coward | about a year ago | (#45249809)

"Compilers are pretty simple"

Hmm, that's at odds with pretty much everyone and everything I've ever heard.

Re: 4.8.2 is not even 2 weeks old (0)

Anonymous Coward | about a year ago | (#45250237)

All types of software can be "pretty simple". Very good software products are few and far between. Software good enough to make programmers happy? That's almost impossible.

Re:4.8.2 is not even 2 weeks old (4, Informative)

Mitchell314 (1576581) | about a year ago | (#45249827)

A lot of generalized software are simple in theory. Until you factor in real world designs, like optimization, handling multiple platforms and architectures, maintainability, stability . . . .

Making something like the GCC is not simple.

Re:4.8.2 is not even 2 weeks old (0)

girlintraining (1395911) | about a year ago | (#45252207)

A lot of generalized software are simple in theory. Until you factor in real world designs, like optimization, handling multiple platforms and architectures, maintainability, stability . . . .

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Knuth

Now, I'll say it again: Making something like GCC is simple. It's just time consuming. It's like a jigsaw puzzle... they're easy regardless of the number of pieces in them, because the overall process doesn't vary regardless of size.

Compilers are jigsaw puzzles. All that extra complexity you ascribe to them is based solely on looking at the size of it and going "zomfg! Where do I start?" ... which is probably why I got downmodded. Nobody understands that just because something is _big_ does not mean it is _complex_.

Re:4.8.2 is not even 2 weeks old (2)

porges (58715) | about a year ago | (#45252327)

It is certainly possible to write a simple, crappy compiler. In reality, optimizing compilers are, yes, complex, because users will not accept the simple, crappy compiler output, and getting the best possible output is hard. There are multiple optimization problems in any compiler, and some of them fight each other.

And that Knuth quote applies to users prematurely optimizing their specific source code before seeing where the time actually is; compiler people have to figure out how to optimize all code in the world with the same compiler. It just doesn't apply to that situation.

Re:4.8.2 is not even 2 weeks old (0)

girlintraining (1395911) | about a year ago | (#45252509)

And that Knuth quote applies to users prematurely optimizing their specific source code before seeing where the time actually is; compiler people have to figure out how to optimize all code in the world with the same compiler. It just doesn't apply to that situation.

It applies more strongly in that situation than in any other situation. Go back and read the patch notes in GCC and you will find plenty of examples where over-zealous optimization led to unexpected behavior and failure. There are even a few notes for options regarding optimization in the man pages that say "You probably don't want to do this. It'll break your program if it does x or y, and the compiler can't tell if you're doing x, or y. Only enable if you are sure it doesn't do these things."

Re:4.8.2 is not even 2 weeks old (5, Insightful)

Anonymous Coward | about a year ago | (#45249861)

What's your point? 4.8.2 is the second bugfix/stabilization release of 4.8.0 which was released in March this year. Should they stop releasing bug fixes as soon as they start developing the next generation compiler? Should they refrain from any new developments until the old version has proven to be bug free?

What's wrong with continuing development that will likely result in a new version release next year?

Re:4.8.2 is not even 2 weeks old (4, Insightful)

gweihir (88907) | about a year ago | (#45250389)

My guess would be that some people just do not understand how release numbers work...

Re:4.8.2 is not even 2 weeks old (4, Interesting)

CurryCamel (2265886) | about a year ago | (#45250761)

Strange - everyone is constantly using the bleeding edge Clang, as a new version is popped out every six months, and nobody is complaining about that (loudly, at least). Just try and file a bug against last year's clang, and the first question asked is "does it work on 3.3?". If it does, that bug is closed, with no more thought to it.

If LLVM can (quoting the insert) surpass GCC with this release method, then why should GCC not adapt a more rapid pace to accomodate contemporary fashions in opensource? Adapt or die.

BTW, has anybody else noticed the change in time? Way back when, GPL:ing your compiler was the right thing to do, forcing it to be open source. This way GCC devs knew improvements would be fed back to the main line. But nowdays (I argue), LLVM's more liberal license is giving it an edge in the way industry is taking an interest. LLVM/Clang is becoming the "obvious" choice when developing a custom compiler, as you don't have to contribute your stuff to mainline LLVM.
But the rapid pace of LLVM makes it actually cheaper to do so, due to lesser maintenance costs. Because your custom compiler you sell your clients is certainly not versioned against the current source tree, forcing you to jump through hoops backporting bugfixes from old LLVM snapshots.
This makes LLVM getting the same improvements as GCC would get due to the license issue due to a carrot, not a stick. While still keeping the PHBs happy because of the license.

Re:4.8.2 is not even 2 weeks old (1)

Anonymous Coward | about a year ago | (#45251629)

Yet LLVM's so-called "liberal" license (I'd rather call it a encourage-others-to-rip-off-your-hard-work license) allows GCC to re-use their code to improve GCC, and they cannot do the same. It's a losing game for those who are not GCC.

Re: 4.8.2 is not even 2 weeks old (-1)

Anonymous Coward | about a year ago | (#45252295)

linux faggots will use anything as long as it is free. Their code is of such horrible quality that even intel compilers can't do much for it.
One day redhat will wake up and start acting like a real business instead of contributing to the mountain of shit that linux has become.

C99 Anytime Soon? (0)

Anonymous Coward | about a year ago | (#45249681)

That's great that they have color diagnostics. When will they finally fully support a standard from 14 years ago?

Re:C99 Anytime Soon? (0, Insightful)

Anonymous Coward | about a year ago | (#45249703)

Most projects don't use C99 anyway.

Re:C99 Anytime Soon? (0)

Anonymous Coward | about a year ago | (#45249737)

[Citation needed]

Re:C99 Anytime Soon? (5, Funny)

Anonymous Coward | about a year ago | (#45249775)

Most projects don't use C99 anyway.

So your defense is that gcc users don't use features unimplemented in gcc?

Re:C99 Anytime Soon? (1)

segin (883667) | about a year ago | (#45251739)

Essentially.

Re:C99 Anytime Soon? (1)

Anonymous Coward | about a year ago | (#45249717)

What features do you want to use that's not currently exposed by their incomplete c99 implementation?

Re:C99 Anytime Soon? (1)

Carewolf (581105) | about a year ago | (#45250713)

C11 is more important, and also fixed so it is compatible with C++. Don't expect any C++ compilers to support the bad parts of C99.

Re:C99 Anytime Soon? (2)

maxwell demon (590494) | about a year ago | (#45250947)

GCC is not just a C compiler, but a compiler collection (GCC = GNU Compiler Collection), which especially contains the C compiler gcc (= GNU C Compiler), and in addition the C++ compiler g++.

Re:C99 Anytime Soon? (1)

maxwell demon (590494) | about a year ago | (#45250957)

That should have been: "... not just a C++ compiler, ..."

Reminder to self: Preview!

How about parsable output (4, Funny)

MichaelSmith (789609) | about a year ago | (#45249707)

Perhaps in json?

Re:How about parsable output (-1, Troll)

Anonymous Coward | about a year ago | (#45249727)

Did you take time off of beating your wife to post here today?

Re:How about parsable output (3, Funny)

Anonymous Coward | about a year ago | (#45249795)

How can the compiler be more sparkly?

Can it compile directly to my 3D printer?

Does it output rainbows and unicorn farts?

Re:How about parsable output (0)

Anonymous Coward | about a year ago | (#45249831)

Didn't you get the memo? Clang already rides a 3D printed unicorn over a sparkly rainbow! Clang is so far ahead of GCC, Clang writes your code for you!

Re: How about parsable output (0)

Anonymous Coward | about a year ago | (#45250271)

Writes my code for me? That explains why my current project is taking so long ... and why I don't seem to recognize the "this works even if you don't understand the code, so don't screw with it" comments I'm finding.

Re:How about parsable output (2, Informative)

Anonymous Coward | about a year ago | (#45249851)

Parsable output is the root of all Evil I tell you, it allows proprietary software (yuck) to interface with FREE software. That is bad and cannot be allowed.

GCC has a history of convoluted design and a disdain for well defined interfaces to make use with non-free hardware harder. Parsable output would allow you to completely bypass the GPL, so this is never going to happen in the flagship GNU project.

Re:How about parsable output (2)

theshowmecanuck (703852) | about a year ago | (#45249867)

Yeah, I thought the big thing about clang aside from being newer is that it isn't GPL.

Re:How about parsable output (0)

Anonymous Coward | about a year ago | (#45250229)

Well I guess that's a good thing if you hate freedom.

Re:How about parsable output (0)

Anonymous Coward | about a year ago | (#45250047)

with non-free hardware harder

ups, meant software (should not type while half asleep).

Re:How about parsable output (1)

MichaelSmith (789609) | about a year ago | (#45250067)

Nuts. I just want to display meaningful compilation results when I compile from within nedit.

Re:How about parsable output (0)

Anonymous Coward | about a year ago | (#45250387)

Now that's how you do a backhanded compliment.

Re:How about parsable output (1)

maxwell demon (590494) | about a year ago | (#45251089)

While I see why someone with inadequate knowledge might see that as troll, the first line quite adequately gives RMS's line of argumentation against well-defined interfaces to the internals. Yes, it's a case of ideology combined with paranoia causing technical inferiority. And it's a sad case, because it allows all those GPL haters to claim that it is the less restrictive license which allows LLVM/Clang to thrive, when in reality it's the superior design.

Re:How about parsable output (0)

Anonymous Coward | about a year ago | (#45249857)

That won't happen since it could make it _easier_ to integrate with _non-free_ development environments.

Re:How about parsable output (-1)

Anonymous Coward | about a year ago | (#45249895)

You mean: Make it more relevant and stimulate innovation? Yeah, that would be bad.

meh (-1)

Anonymous Coward | about a year ago | (#45249751)

Oooooooooo pretty colors to impress the clang idiots who can't tell the difference between compile-time speedup and run-time speedup.

I don't see any huge improvements in that list of changes. I'll be in no hurry to upgrade, thanks.

Re:meh (1)

maxwell demon (590494) | about a year ago | (#45249847)

I'll be in no hurry to upgrade, thanks.

That's good, because you'll have to wait until next year anyway.

GCC still has a long way to go... (-1, Flamebait)

Anonymous Coward | about a year ago | (#45249875)

GCC is still a hobbyist tool and has a long way to go before it can even be compared to things like Intel/Oracle compilers.

Re:GCC still has a long way to go... (4, Interesting)

gweihir (88907) | about a year ago | (#45250411)

With some insight into how some people write real high-quality enterprise grade software, I can confidently state that you are completely clueless. In addition, many enterprises that are critically depending on IT infrastructure are now considering replacing Solaris with Linux (RHEL typically), due to problems with basically _everything_ Oracle makes. And of course the most critical part of RHEL (the kernel) is compiled with GCC.

You are suffering from the common misconception that things you pay for are better. Psychologically well researched, but it does not hold up in reality, and is just a specific form of stupidity, i.e. ignoring reality to take comfort in your own misconceptions.

Re:GCC still has a long way to go... (2)

TheRaven64 (641858) | about a year ago | (#45250423)

The above post was correctly marked as flamebait, but there's a grain of truth in it. ICC, for example, still does a much better job at vectorisation than gcc or clang (clang with polly enabled does about as well, significantly better in some cases). The autoparallelisation stuff in the Sun, uh, Oracle, compiler is also pretty impressive on certain workloads.

Re:GCC still has a long way to go... (1)

serviscope_minor (664417) | about a year ago | (#45250565)

but there's a grain of truth in it.

Not really.

ICC, for example, still does a much better job at vectorisation than gcc or clang

So? gcc has much better support for C++11 and C++14, and supports many more architectures and platforms. ICC being better at one (important, but still one) aspect does not make the claim that "gcc is a hobbyist tool" have a grain of truth.

GCC runs a substantial fraction of the world's infrastructure: it is in absolutely no way a hobbyist tool.

Re:GCC still has a long way to go... (0)

Anonymous Coward | about a year ago | (#45250683)

So? gcc has much better support for C++11 and C++14

Much better? [apache.org] Maybe "a tad better" And the things icpc is missing are not so important. But that wiki (while the best reference for it that I know of) is out of date [intel.com] , so if you are comparing the latest version of each, I think you'd find that they are fairly compatible.

Re:GCC still has a long way to go... (2)

petteyg359 (1847514) | about a year ago | (#45252135)

Yes, "much better", going by available data. Here's that table with version numbers converted into dates. I deleted rows with missing data for either compiler, and removed other compilers. If I get bored, I might actually go through their changelogs for missing data.

https://docs.google.com/spreadsheet/pub?key=0AsJ4G9Bsq42ddHRjbmJNbldUbWxFckpITTFQUkVJUUE&output=html [google.com]

Re:GCC still has a long way to go... (1)

jones_supa (887896) | about a year ago | (#45250457)

What do people have to say about the IBM XL C++ compiler? Is it good?

Re:GCC still has a long way to go... (0)

Anonymous Coward | about a year ago | (#45250467)

It's crazy expensive. But it's good. It's the most typical compiler for BlueGene machines, for example. But you can buy a few gcc licenses for the same price.

Re:GCC still has a long way to go... (0)

Anonymous Coward | about a year ago | (#45250483)

Oh, and their C++11 [apache.org] support is atrocious.

Re:GCC still has a long way to go... (1)

loufoque (1400831) | about a year ago | (#45251145)

It's so good that you should use the experimental Clang port instead or the outdated GCC whenever you can.

Re:GCC still has a long way to go... (5, Insightful)

loufoque (1400831) | about a year ago | (#45251139)

As a member of both the C and C++ standards committees, and as a CEO of a company that sells C++ libraries to businesses for high-performance computing, I have to disagree with you.

The Oracle/Sun and IBM compilers are the worst C++ compilers available.
Intel is also pretty bad, despite touting good standards conformance and being designed for runtime speed, it deals very badly with abstraction penalties, and is extremely slow to compile.
Microsoft's compiler is also pretty bad, both at compilation speed, standards conformance, and runtime speed, with each new version introducing quirks and regressions (they have acknowledged major codegen regressions in the recent releases and are investigating them)

If you want a good C++ compiler, GCC or Clang are the only tools available.

Re:GCC still has a long way to go... (0)

Anonymous Coward | about a year ago | (#45251189)

As a member of both the C and C++ standards committees

I don't know whether that's a good sign for Slashdot, or a bad sign for C/C++....

Re:GCC still has a long way to go... (0)

Anonymous Coward | about a year ago | (#45251841)

Don't worry it's not that hard to be a CEO and a member of a committee.

Re: GCC still has a long way to go... (-1)

Anonymous Coward | about a year ago | (#45251915)

let me rephrase that, since some took it as flamebait. GCC is a pretty good tool for cheap ass wanna be programmers who don't take their own wok seriously. Compared to an intel compiler, it is a fucking joke.
Any business that decides to skimp out on cost, deserves the crap that is generated.
It's not linux's fault that it is infested with cheap ass retard programmers.

Quality (0)

Anonymous Coward | about a year ago | (#45249915)

So, no improvements to the quality of generated code from existing source for existing platforms?

Re:Quality (0, Redundant)

Anonymous Coward | about a year ago | (#45250091)

No because GCC is reacting to what Clang does and Clang is still choosing which existing optimizations to enable at which -O levels. [phoronix.com] Don't expect any improvements of any consequence from either GCC or Clang, while they're still competing over what colors their error messages should be, because hipster coderz these days are so incredibly dumb that colored error messages are seriously important fashion statements that they actually care about. The clangy-gee-see-see rivalry is laughably idiotic.

Re:Quality (3, Interesting)

TheRaven64 (641858) | about a year ago | (#45250441)

That's a crazy misrepresentation. The Phoronix article is mentioning the fact that clang now enables the autovectorisers at -O2, but it doesn't cover the reason for the switch. -O2 is intended as the default optimisation level for release builds. It should (almost) always produce faster code than -O1 or -O0, at the cost of greater compile times. Enabling an optimisation at that level means that it's unlikely to cause slowdowns. In 3.3 and in GCC, the autovectoriser can create larger code and more vector-scalar register copies that cause a slowdown that offsets the speedup from using the vector ALUs. As such, they're only run if explicitly enabled, so you people with performance-critical code can test them and see if they actually do provide a speedup.

As to the quality of the error messages, I recently fixed a number of bugs in some third party code that were raising warnings with clang. One warning, that a comparison was the result of a comparing an unsigned value as being less than zero, occurred in four string processing loops in the code. In each case, it was iterating over characters in a user-provided string and appeared to be a security hole. Fixing it was trivial (change the type to a signed integer), but I like it when my compiler points out serious bugs in code that I'm compiling.

Biggest boon to GCC: lack of hackability (0, Flamebait)

gentryx (759438) | about a year ago | (#45249961)

...which is exactly why some folks are flocking to CLANG. Sure, not everyone wants to extend/modify his compiler, but actively preventing [ycombinator.com] people from reusing your code isn't exactly what you should do if you want to keep a community thriving.

Re:Biggest problem with GCC: lack of hackability (1)

Anonymous Coward | about a year ago | (#45249981)

Why does your subject imply that boon means the opposite of "a thing that is helpful or beneficial"?

Irony not lost on me (0, Flamebait)

tuppe666 (904118) | about a year ago | (#45250177)

...which is exactly why some folks are flocking to CLANG.

No Apple is pushing CLANG for exactly the reason that they want to use BSD license in a take not give fashion...how hackable is it; Xcode(SDK) will only work on Mac OS X. Looking forward to proprietary extensions :)

On a side note wasting my time to by providing a link that neither promotes your conclusion or your facts its derived from is offensive.

The irony is not lost on me that you do this in response to an article where GCC continues to move forward at a breakneck pace.

Re:Irony not lost on me (5, Informative)

mean pun (717227) | about a year ago | (#45250233)

No Apple is pushing CLANG for exactly the reason that they want to use BSD license in a take not give fashion...how hackable is it; Xcode(SDK) will only work on Mac OS X. Looking forward to proprietary extensions :)

Huh? Apple is putting a lot of work in llvm (the general compiler framework), and they give that work away under the BSD license. They are most certainly not only taking, they are also giving a lot. llvm is highly portable, and is certainly not restricted to Mac OS X (or C/C++ compilation, for that matter). In fact, lots of BSD distributions (and Minix) use llvm as their compiler of choice, because they don't want GPLed software. Similarly, clang (the c/c++ compiler on top of llvm) is highly portable, under a BSD license, and Apple is putting a lot of work in it. Moreover, Apple is eating its own dog food, and using llvm/clang to compile most of Mac OS X, which is a solid guarantee for the quality of the resulting compiler, and is therefore another highly significant contribution.

It is true that Xcode (the Integrated Development Environment (IDE)) is not free, but that does not diminish the contributions that Apple is making to llvm and clang.

Re:Irony not lost on me (1, Insightful)

Electricity Likes Me (1098643) | about a year ago | (#45250447)

GPL does one very important thing well: it keeps the community alive. As long as people are modifying GPL code, they're obliged to contribute those modifications back.

The problem with the BSD license is, as soon as Apple feels they have the market sewn up, those patches are going to stop flowing very quickly and probably not for the most rational reasons - remember, it's managers and executives who make these decisions, not coders.

Re:Irony not lost on me (0)

Anonymous Coward | about a year ago | (#45250711)

You don't get to present soothsaying as fact. Which market will Apple need to see up to trigger CLANGageddon, and why would this drive them to stop contributing patches?

The fate of Darwin could be a precedent, yet this isn't remotely the same situation. There was so little take-up of Darwin there was little point in continuing to distribute ISOs. It's still possible to build from the sources, but slightly pointless. Why choose Darwin over any existing and well supported BSDs? I run OS X and OpenBSD. I've no desire or need to build Darwin from sources.

BSD is not inherently worse than the GPL. Would we even have CLANG/LLVM if GPL was the only option? Choose the licence that suits your desires.

Re:Irony not lost on me (2)

maxwell demon (590494) | about a year ago | (#45251173)

As long as people are modifying GPL code, they're obliged to contribute those modifications back.

Wrong. I can modify gcc in whatever way I want without ever giving anyone the changed code. The only restriction is that if I decide to give anyone the modified code, I have to do so under the terms of the GPL. But as long as I keep it for myself (e.g. using a modified gcc to compile my own programs), nobody forces me to provide the modifications to anyone.

Re:Irony not lost on me (4, Informative)

Goaway (82658) | about a year ago | (#45251207)

Apple created and owns clang. If they wanted to stop distributing the source, they could do so no matter if it were GPL and BSD licensed. It's theirs to do what they want with.

They're giving it all away for free with zero obligation to do so, and all you can do is criticise them for somehow still not giving enough?

Re:Irony not lost on me (4, Informative)

cheesybagel (670288) | about a year ago | (#45252499)

Apple "created" clang by hiring the LLVM creator. It was started in academia.

Re:Irony not lost on me (1)

w_dragon (1802458) | about a year ago | (#45251891)

No, not at all. If you modify GPL software you don't have to contribute anything. If you distribute the changed software then you must make available the source code to the people you have distributed the binary to, and you must license it in a way that is compatible with the GPL. So if I take GCC,fix some bugs, and sell it I must give my customers the source code I have created. I must license it to them with terms that allow them to distribute it freely, so long as they continue to follow the GPL when they distribute it. I am under no obligation to give it away to the world for free, however I can not stop my customers from doing so.

Wat? (1, Troll)

gentryx (759438) | about a year ago | (#45250307)

I'm not sure whether I understood your post correctly as it seems to garbled be yes? If you doubt that RMS is [slashdot.org] objecting plugins [gnu.org] in GCC then you're apparently new to /. and GCC.

BTW: not just Apple is pushing CLANG (and thereby LLVM), other companies include NVIDIA (CUDA uses LLVM [slashdot.org] ) and IBM (CLANG was ported to Blue Gene/Q [anl.gov] ), just to name a few.

Re:Wat? (3, Informative)

anonymov (1768712) | about a year ago | (#45250329)

If you doubt that RMS is [slashdot.org]objecting plugins [gnu.org] in GCC then you're apparently new to /. and GCC.

Wait, wut? You were talking about GCC, why are you equating "GCC" and "RMS" now? "RMS opposes hackability in GCC" and "GCC opposes hackability" are two different statements, don't you think? RMS is not quite at the post of BDFL for GCC project, unlike Linus for Linux or Guido for Python.

And did you know that both plugins and GIMPLE from your previous quote are already in GCC? Your posts look pretty silly with that knowledge: "GCC opposes hackability - see, they don't want convenient IR and plugins! (except they have plugins and had IR at the time of your quoted post about Stallman hating it)"

Re:Wat? (2)

maxwell demon (590494) | about a year ago | (#45251203)

And did you know that both plugins and GIMPLE from your previous quote are already in GCC?

But if you read the GCC mailing lists from the relevant time, you'll see that the gcc developers had a very hard time convincing RMS to give his OK to plugins (I didn't read the mails from the time when GIMPLE was introduced, so I can't comment on that).

Good company indeed. (1)

Anonymous Coward | about a year ago | (#45250353)

Yeah, because I feel so cozy in the company of Apple, Nvidia and IBM. Still I miss sorely Oracle, Adobe, Sony, Microsoft, the RIIAA and... how was that Myhrvold fixture called? Ah, yes! Intellectual Ventures.

Technically LLVM is shiny and all, but I won't touch it with a ten-foot pole.

I always think Apple's biggest stake in CLANG (or any competition to GCC) is Jobs's butthurt from good ol' NeXT times.

Re:Irony not lost on me (0)

Anonymous Coward | about a year ago | (#45250399)

No Apple is pushing CLANG for exactly the reason that they want to use BSD license in a take not give fashion

Apple supported GCC until they moved to GPL v3. The GPL v2 was more than enough to allow give and take style software development and is still used by the linux kernel. The GPL v3 and apples decision to create their own compiler is fully about hardware patents/free software movement (full access to iPhone/iPad app development/deployment for free) and completely unrelated to open source.

Re:Irony not lost on me (0)

cheesybagel (670288) | about a year ago | (#45252527)

So that Apple could instead earn money by forcing you to pay for a patent license of work someone else did? That would be rich. Fact is the first OSI approved open-source licenses which gave such patent cross-licensing as the GPLv3 came from corporations like IBM namely their Eclipse Public License. Which other third party vendors find perfectly fine to use. I doubt there is an IDE with more third-party extensions (including paid extensions) than Eclipse.

Re:Biggest boon to GCC: lack of hackability (1)

Anonymous Coward | about a year ago | (#45250243)

... 1101 days ago

ICWUDT (a guy who modded you up doesn't, though).

Three years is such a short period in software development, and nothing ever changes in development strategy! Even the quote mentions already included at that time "GIMPLE and friends", so it seems even if Stallman didn't want them there, he failed to prevent it.

Do troll harder.

PS: "boon" - this word doesn't mean what you think it means.

Re:Biggest boon to GCC: lack of hackability (5, Interesting)

serviscope_minor (664417) | about a year ago | (#45250275)

...which is exactly why some folks are flocking to CLANG.

People are flocking to CLANG for a variety of reasons. A large part seems to be because for some reason the GNU tools have become deeply unfashionable.

LLVM has some structural advantages (due to being youger), but despite that all, GCC is comfortable keeping ahead of CLANG in both the optermizer and C++ support, so it cant be that bad.

Sure, not everyone wants to extend/modify his compiler, but actively preventing people from reusing your code isn't exactly what you should do if you want to keep a community thriving.

RMS is but one voice on the steering committee. He can say what he wants (and does), but the committee doesn't have to listen.

That sad, when taking the long term into account, his whacky ranting and raving has the sad tendency to come true.

Re:Biggest boon to GCC: lack of hackability (0)

Anonymous Coward | about a year ago | (#45250343)

BTW: Who the heck is this "Root Mean Square" (RMS) that thou speakest of?

Re:Biggest boon to GCC: lack of hackability (2, Interesting)

Anonymous Coward | about a year ago | (#45250847)

>GCC is comfortable keeping ahead of CLANG in both the optermizer and *C++ support*, so it cant be that bad.
Um. No it isn't. Clang finished c++14 support a few weeks ago. Dev builds of gcc aren't there yet.

Re:Biggest boon to GCC: lack of hackability (4, Informative)

Anonymous Coward | about a year ago | (#45251417)

As far as C++(11,14) goes, clang is more mature, faster *and* it produces faster code (the last mainly due to libc++). I fail to see how is GCC keeping ahead, let alone comfortably. Also, clang is a self-hosting C++ compiler -- unlike gcc, which is written in C. That helps an awful lot.

PS: Getting a two-fold speedup when going from libstdc++ to libc++ (with STL-heavy code) is not unheard of. But yes, that's anecdotal. I don't have any good benchmarks, as far as anything like that even exists.

Re:Biggest boon to GCC: lack of hackability (0)

Anonymous Coward | about a year ago | (#45251935)

Ironically its the GPL v3 that is hurting GCC. Despite your outright lie about CLANG, GCC is not that easy to work with because of the GPLv3 and the sloppy code.

Gcc? Haha Goog rules the roost so go home already (0)

Anonymous Coward | about a year ago | (#45249965)

since we don't need your kind around here no more.

Fat Loss Supplements pills (-1, Offtopic)

top_roz (3411003) | about a year ago | (#45250135)

When it comes to losing weight, the immediate solution that comes to the mind is following a diet, which is free of calories. Moreover, a majority of people want rapid results in order to achieve that perfectly carved figure for sporting the best looks and flaunting designer clothes. The trouble with this concept is that people often go haywire while choosing their diet and end up with severe health problems that are difficult to cure http://dietsupplementspills.com/ [dietsupplementspills.com]

Don't try to be more Catholic than the Pope... (0)

Anonymous Coward | about a year ago | (#45250291)

Serious, while testing the latest compiler in my organsation we really were flabbergasted by the aggressive loop optimization in 4.8. A great feature if everyone would stick to the most conservative coding standards, but a hell in practice. Reducing the iteration count of loops without a single warning, who thought that was a great default mode of operation should be shot, quartered and shot again.

Re:Don't try to be more Catholic than the Pope... (2)

gweihir (88907) | about a year ago | (#45250445)

Aehm, care to give an example? It also been well-known for a long time that if you want to debug code generated by GCC you should use -O0 (at often not that much performance loss...), as with higher optimizations parts of your code and variables may well be missing in the code. In fact, GDB even warns you about this in startup.

Now, that said, did this change the timing characteristics or the actual computation performed? Because if it just changed the timing, then you are too stupid to read the documentation and use -O0 and all your vitriol is misdirected. If it changed the function, example please and make sure to file a bug-report.

Re:Don't try to be more Catholic than the Pope... (0)

Anonymous Coward | about a year ago | (#45251151)

You didn't even read my comment properly, did you ? Hell sure it changed the function: It completely broke the application. In this case the problem was that the compiler made wrong assumptions about an array length. When discussing this on the GCC irc channel the reply was "fix your code". Especially C is used for really low-level stuff with sometimes dirty tricks to get things working at all, and our fix was to ditch gcc for another compiler.

Re:Don't try to be more Catholic than the Pope... (1)

gweihir (88907) | about a year ago | (#45251505)

You claim "badly broken", yet you provide zero evidence. I suspect that you did something emphatically not covered by any sane use of the C language (and by the language specification) and that you did shoot yourself in the foot. "Dirty tricks" are never acceptable and never needed. If you really have to go that low-level, use embedded assembler. Never use dirty tricks for things that embedded assembler would have solved cleanly, that is just plain incompetent. And never expect a compiler to compile something in a specific way, that is _not_ what a compiler is for! The compiler is free to compile in any way it sees fit, as long as the language specification is respected.

So, my conclusion at this time is that you did something really stupid and now blame others for it. Pathetic.

Re:Don't try to be more Catholic than the Pope... (1)

Rockoon (1252108) | about a year ago | (#45251819)

Not to mention the fact that the higher optimization levels are not ever guaranteed to produce correct code... many optimizations are only possible under assumptions that cannot be guaranteed at compile time, but are taken for granted to be the case at runtime. Perhaps the simplest such assumptions is that functions that take two input pointers do not encounter cases where those two pointers point to the same memory in a way that could break register usage optimizations.

Some Clang stuff (2)

jones_supa (887896) | about a year ago | (#45250471)

There's an interesting Clang talk at Channel9: The Care and Feeding of C++’s Dragons [msdn.com] . Speaker: Chandler Carruth, Clang lead, Google.

Re:Some Clang stuff (2)

loufoque (1400831) | about a year ago | (#45251199)

That description is ambiguous. Chandler's isn't the "Clang lead". He's the guy that leads Google's developments in Clang.
The main developers of both Clang and LLVM are from Apple.

Re:Some Clang stuff (0)

jones_supa (887896) | about a year ago | (#45251285)

Ah yes, that's indeed an important correction. :)

Undefined behavior sanitizer (0)

Anonymous Coward | about a year ago | (#45250699)

Does anyone have any information about the undefined behavior sanitizier?

Re:Undefined behavior sanitizer (1)

maxwell demon (590494) | about a year ago | (#45251279)

Well, if it is undefined, there cannot be any information about it, right? ;-)

too little too late (-1)

Anonymous Coward | about a year ago | (#45250705)

if GCC wants to survive they are going to have to dump their unfree license and adopt one that is more business friendly. at the rate people are dumping GCC now only hobbyists will be using it in 5 years.

GCC - let it die. (-1)

Anonymous Coward | about a year ago | (#45251045)

Let GCC die already... CLANG is the new de-facto standard.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?