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 Turns 25

timothy posted more than 2 years ago | from the old-enough-to-ethically-date dept.

GNU is Not Unix 192

eldavojohn writes "With the release of GCC 4.7.0, the venerable and stalwart constant that is the GNU Compiler Collection turns twenty five. More ISO standards and architectures supported with this release and surely more memories to come from the compiler that seems to have always been."

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

lolcompilers (0, Troll)

Anonymous Coward | more than 2 years ago | (#39445609)

pre-javaScript relics

Re:lolcompilers (5, Insightful)

multiben (1916126) | more than 2 years ago | (#39445653)

You must be a high quality programmer.

Re:lolcompilers (-1)

Anonymous Coward | more than 2 years ago | (#39446183)

no i am eleete cod3er

It's hard work being a JavaScript Rockstar. (5, Funny)

Anonymous Coward | more than 2 years ago | (#39446305)

Your attitude makes me think that you're not a JavaScript Rockstar. Well I am, and let me tell you, it's not easy being one!

You probably only know Pearl or See Plus Plus or See Sharp or one of those other old hat langs that nobody uses any more. You also probably only write software that's Desktop Scale or maybe even Server Scale. Well that's Old Hat and it's Small Hat!

Us pros, we use JavaScript because it's the best language there is. In fast, it's so good that it's the only one I need to know. It's so fast to work with that I can create five social media applications before you even turn your compiler on! And since I use node.js my web app will scale to the Web And Beyond.

JavaScript has the best dev tools around. I hear that you guys have Visual Studios or something but we have alert(). It's like your Visual Studios but it's a lot more powerful. But we only use it for the Hard Problems because JavaScript makes it so easy to write perfect software. In fact, I haven't created a bug in almost 3 years because JavaScript is perfection and I'm thus perfection because I use JavaScript.

JavaScript is the only option today. If you're not using JavaScript, and only JavaScript, then your code is Old Hat. If your code is Old Hat then you're not a JavaScript Rockstar like me and my colleagues. And if you're not a Rockstar, then you probably shouldn't be talking about programming.

Re:It's hard work being a JavaScript Rockstar. (1)

multiben (1916126) | more than 2 years ago | (#39446713)

Ha hahaha ha ha! So true.

Re:It's hard work being a JavaScript Rockstar. (2, Interesting)

Anonymous Coward | more than 2 years ago | (#39446725)

I know your joking and I think I can smell sarcasm even but you are not helping our cause one bit.

JavaScript as a language is not the problem it can be used wisely. It is has been intentional been feature ridden and with the state of the browser wars going on anything complex is a security risk. The browser wars have also probably left it with the worst development tools known to man.

Don't even get me started complaining about how every site doesn't work because it uses JavaScript, and that is sent as raw code on every request unless you pull magic tricks to combine, minify, compress and CDN serve.

It's a retarded misuse of an okay idea and just begs for every thing to break with it's modern day usage.

Re:It's hard work being a JavaScript Rockstar. (1)

Aardpig (622459) | more than 2 years ago | (#39446919)

It is has been intentional been feature ridden....

WTF?

Happy birthday GCC! (5, Funny)

hamster_nz (656572) | more than 2 years ago | (#39445615)

Hey GCC, only one slice of cake for you - you are big and slow enough at the moment (but I love you anyway).

OH NO! It's like I'm married to GCC!

Re:Happy birthday GCC! (2)

iluvcapra (782887) | more than 2 years ago | (#39445667)

Codependency destroys families.

Re:Happy birthday GCC! (4, Funny)

mug funky (910186) | more than 2 years ago | (#39446095)

yes, you need to resolve ALL dependencies to make it work.

Re:Happy birthday GCC! (4, Funny)

hamster_nz (656572) | more than 2 years ago | (#39446247)

It's best captured in words of that old "Bread" song from the 70s...

"I want to make it with you"

Re:Happy birthday GCC! (1)

93 Escort Wagon (326346) | more than 2 years ago | (#39446613)

Given the license used by gcc, "Freedom" would also have been acceptable.

Re:Happy birthday GCC! (1)

Anonymous Coward | more than 2 years ago | (#39446871)

Codependency destroys families.

What's code-pendency?

Re:Happy birthday GCC! (3, Funny)

beelsebob (529313) | more than 2 years ago | (#39446067)

Run off with a young, pretty, thin floosy [llvm.org] instead!

Re:Happy birthday GCC! (3, Interesting)

hamster_nz (656572) | more than 2 years ago | (#39446269)

I've actually been tempted to have a fling with TCC [bellard.org] .

Small, tight, flexible, low maintenance and can do the business just about anywhere.

Re:Happy birthday GCC! (1)

serviscope_minor (664417) | more than 2 years ago | (#39446683)

tight,

But the code it generates isn't. With -O3, the majority of time is soent in the optimizer in GCC, and the optimizer is really pretty impressive.

Re:Happy birthday GCC! (1, Funny)

Anonymous Coward | more than 2 years ago | (#39446767)

gcc's optimizer, much like Kim Kardashian's pussy, is smelly, loose, full of bugs, and to be avoided at all costs.

Re:Happy birthday GCC! (1)

Aardpig (622459) | more than 2 years ago | (#39446929)

Maybe when it can compile F2003/F2008....

Re:Happy birthday GCC! (2)

phantomfive (622387) | more than 2 years ago | (#39447005)

If you really want to speed up your GCC compiling, the fastest speed boost you can get is to compile more than one file at a time. Seriously, try it; it's a massive speed boost.

I respect the gcc... (0)

Anonymous Coward | more than 2 years ago | (#39445617)

...but I wish its development wasn't so inner-circle. If you thought that Free software = bazaar model, you haven't met gcc.

Re:I respect the gcc... (3, Interesting)

Tubal-Cain (1289912) | more than 2 years ago | (#39445771)

...wasn't GNU Emacs used as the example of the "cathedral" model?

Re:I respect the gcc... (2, Informative)

Anonymous Coward | more than 2 years ago | (#39446027)

Those were the days before the EGCS fork.

Betrayed? NEVER FORGET! (-1)

Anonymous Coward | more than 2 years ago | (#39445633)

#
                  Tor Browser Bundle for Linux (2.2.35-8) "EVIL bug"
                                                  *** NEVER FORGET ***
#
- http://seclists.org/bugtraq/2012/Mar/85 [seclists.org]
- http://www.securityfocus.com/archive/1/522003/30/0/threaded [securityfocus.com]
#
"There is an EVIL bug in at least the Linux (2.2.35-8) Tor Browser Bundle start-tor-browser script. It will log things
like domain names to a file in the root of the browser bundle."

https://trac.torproject.org/projects/tor/ticket/5417 [torproject.org]

Ticket #5417 (new defect)

RelativeLink.sh in Tor browser bundle has small typo causing debug mode to be always turned on

Reported by: cypherpunks
Priority: critical
Component: Tor bundles/installation

Description

TBB starts in debug mode disregardless of --debug switch used or not. This is caused by small bug on line 208 on
RelativeLink.sh, where it says

if [ "${debug}" ];

where it should say

if [ "${debug}" == 1];

or

if [ ${debug} -eq 1 ];

#
Thank you for the warning. I expected something like this to happen, given the last slip up with a mistake in FF versions. This, "error", if you wish to call it such, shouldn't have happened. Again, this is a lack of testing.

I hope no one in Iran, China, or other freedom starved regions were screwed because of this.

I hope a fix is released and quickly.

These mistakes should be posted in the Tor announcements mailing list (no announcements at all since Dec/11 is pathetic) and on the blog.

It would help Tor users even more if you were to actually create web forums for discussions (but I doubt you will, we've only been asking for this for years!) where you could sticky-pin these types of mistakes and communicate better with the broad range of users.

A large number of people will never use a bug tracker, and/or never use mailing lists. They are simpler minded people or too busy, this is where web based discussion forums come in. Users should not have to scramble to unofficial .onion forums which are up one day and down the next and which may (and have in the past!) contain malicious posts/threads to target the user's browser and/or Tor itself.

With errors like this, perhaps you should let Mickey Mouse sign the future Linux release bundles with his fictional GPG key. He couldn't do any worse.

I've also noticed FF crashing more often since the last few releases.

I guess it's time for us Linux bundle users to run W.I.N.E. and the Windows version of the bundle on Linux so we know we are not getting borked with some new fantastic bug or lack of oversight like this again.

But will this post be approved for others to see, or swept under the rug like one previous post about a similar issue.

Now I'm looking forward to the next release, not for use, but just to see what type of bug(s) it may contain. THANKS!

#
Nick Mathewson
Mon, 19 Mar 2012 09:40:43 -0700

It seems that a fix was merged yesterday: see
https://trac.torproject.org/projects/tor/ticket/5417 [torproject.org] and
https://lists.torproject.org/pipermail/tor-commits/2012-March/041036.html [torproject.org]
.

I bet there will be new TBBs out very soon.

In the meantime, Linux users should delete vidalia-debug-log and
symlink it to /dev/null. (Haven't tested that, but it should work:

    % ln -sf /dev/null /path/to/vidalia-debug-log
    % ls -l /path/to/vidalia-debug-log

    lrwxr-xr-x 1 username username 9 Mar 19 11:53 vidalia-debug-log
-> /dev/null .)

IMO, this is a really good reason for us to move to getting enough
automation done so we can have nightly TBB builds and catch this kind
of thing *before* actual releases come out.

--
Nick
#
Sebastian Hahn
Tue, 20 Mar 2012 02:20:08 -0700

The bug in TBB is quite severe, and it is against its stated goals and
design principles (one of which is leaving no/as little traces as
possible on disk for later forensics). This bug was severe, it was fixed
quickly, and hopefully nobody was impacted too much. Time to move on.
#
Read and archive these also (to record history for this "EVIL bug":

https://lists.torproject.org/pipermail/tor-commits/2012-March/040941.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040942.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040939.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040945.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040950.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040952.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040953.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041036.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041037.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041038.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041039.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041040.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041043.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041056.html [torproject.org]
#
History won't recall this bug and the severity of it unless you
archive this information and the information at the links issued
above.

Pastel compiler? (4, Funny)

jabberw0k (62554) | more than 2 years ago | (#39445663)

"I then realized that the Pastel compiler functioned by parsing the entire input file into a syntax tree..."

Is that some faded-out version of Pascal, perhaps?

Re:Pastel compiler? (1)

Anonymous Psychopath (18031) | more than 2 years ago | (#39445805)

"I then realized that the Pastel compiler functioned by parsing the entire input file into a syntax tree..."

Is that some faded-out version of Pascal, perhaps?

I imagine it was, since he's talking about what happened in 1984.

Re:Pastel compiler? (1)

Anonymous Coward | more than 2 years ago | (#39445823)

Hey, the Pastel compiler was a critical component of CDE.

Re:Pastel compiler? (0, Interesting)

Anonymous Coward | more than 2 years ago | (#39445899)

Hoping to avoid the need to write the whole compiler myself, I obtained the
source code for the Pastel compiler, which was a multi-platform compiler
developed at Lawrence Livermore Lab. It supported, and was written in,
an extended version of Pascal, designed to be a system-programming
language. I added a C front end, and began porting it to the Motorola
68000 computer. But I had to give that up when I discovered that the
compiler needed many megabytes of stack space, and the available 68000
Unix system would only allow 64k.

Re:Pastel compiler? (0)

Anonymous Coward | more than 2 years ago | (#39446171)

Sounds like what you really needed was 640k.

Re:Pastel compiler? (0)

Anonymous Coward | more than 2 years ago | (#39446753)

WE only need 64k. Suck it.

Re:Pastel compiler? (0)

Anonymous Coward | more than 2 years ago | (#39445945)

Web search suggests it was a real compiler, compiling something very similar to Pascal looking code.

Pastel and LLNL (5, Informative)

Al Kossow (460144) | more than 2 years ago | (#39446483)

Pastel was an extended Pascal compiler developed by LLNL for the S-1 supercomputer project
http://www.cs.clemson.edu/~mark/s1.html [clemson.edu]

It, and several other significant pieces of software, including the SCALD hardware design language
were made freely available by LLNL. I have one version of the compiler, which was donated to the
Computer History Museum by one of its authors. I have been looking for the other pieces since the
late 80's.

If you look at the GNU Manifesto, RMS was also looking at using the MIT Trix kernel in the early days
of the project.

Measured from where? (4, Interesting)

Anonymous Coward | more than 2 years ago | (#39445683)

Are we measuring GCC from the first version called GCC, or are we measuring from the last release of EGCS, which is actually what we're now using and calling GCC? 'cos where the original GCC went, no one followed...

Re:Measured from where? (5, Interesting)

Anonymous Coward | more than 2 years ago | (#39445897)

EGCS stands for Experimental/Enhanced GNU Compiler System. It was a decendant of GCC which used a more open development process. This meant that it included more optimizations and language features than the standard GCC.

This experiment was very successful, and version 2.95 of GCC adopted the EGCS code. Since then GCC has been developed using the same methods as were used for EGCS.

For more information and the official announcement (now historical) see this page and the GCC homepage.

When you have a project fork, like egcs, that gets folded back into the main branch (or even when it becomes the main branch), then the main branch gets to hog all the credit and claim that it was its idea the whole time.

So gcc is and always has been gcc, even when it was egcs. :P

Re:Measured from where? (-1)

Anonymous Coward | more than 2 years ago | (#39446345)

When you have a project fork, like egcs, that gets folded back into the main branch (or even when it becomes the main branch), then the main branch gets to hog all the credit and claim that it was its idea the whole time.

So gcc is and always has been gcc, even when it was egcs. :P

So how does that explain "Gnu/Linux", even though none of the code originally came from Gnu? Oh, I see, the rule is that Gnu always gets to hog all the credit... :P

Re:Measured from where? (0)

Anonymous Coward | about 2 years ago | (#39447305)

When you have a project fork, like egcs, that gets folded back into the main branch (or even when it becomes the main branch), then the main branch gets to hog all the credit and claim that it was its idea the whole time.

So gcc is and always has been gcc, even when it was egcs. :P

So how does that explain "Gnu/Linux", even though none of the code originally came from Gnu? Oh, I see, the rule is that Gnu always gets to hog all the credit... :P

GNU/Linux refers to a Linux distribution, as opposed to the Kernel. Linux on its own is kind of useless. Traditionally, the set of tools and things used by a Linux distribution to turn Linux useful primarily came from GNU. Nowadays there's alternate tool sets like Busybox and Android's custom stuff (Bionic?) which are used in embedded application, so it might be more useful as a way of differentiating. There's probably also more non-GNU stuff in server/desktop distributions though, so I don't know.

Dogma (1)

Anonymous Coward | more than 2 years ago | (#39447047)

Plus, we were always at war with Eurasia.

404 (0)

Anonymous Coward | more than 2 years ago | (#39445733)

File not found :(

Thanks gcc! (5, Insightful)

stox (131684) | more than 2 years ago | (#39445747)

You youngin' have no idea of what kind of crap for compilers we had to put up with until gcc.

25 years of compilation with gcc!

Re:Thanks gcc! (-1, Flamebait)

beelsebob (529313) | more than 2 years ago | (#39446089)

And now gcc too has joined the ranks of "crap compiler" – clang [llvm.org] runs fast, produces faster code, produces better error messages, is more modular, is licensed in a more open way, ...

Re:Thanks gcc! (1)

Anonymous Coward | more than 2 years ago | (#39446175)

clang is nice but it is far from producing efficient code...

Re:Thanks gcc! (0)

Anonymous Coward | more than 2 years ago | (#39446651)

clang is nice but it is far from producing efficient code...

[citation needed] [phoronix.com]

Re:Thanks gcc! (4, Informative)

Anonymous Coward | more than 2 years ago | (#39446227)

No, it doesn't [lwn.net] . Distributions are evaluating it right now and it is failing big time. Even Xcode developers are pissed off [woss.name] that Apple dropped gcc. That shit ain't fully baked, and imbeciles like you who recite Apple propaganda without thought need to pull your heads out of your asses.

Re:Thanks gcc! (2, Insightful)

samkass (174571) | more than 2 years ago | (#39446539)

The guy in that second link doesn't sound very pissed off. And clang definitely has WAY better error messages and analysis/refactoring available to it. As for the codegen, it beat GCC by a wide margin when it first came around, but GCC seems to have surpassed it again in more recent versions.

But the key for any commercial entity is that clang beats the pants off any GPLv2-licensed compiler, and GPLv3-licensed code is pretty much irrelevant to most applications. So GCC is doing a great job for the insulated linux world, and hopefully clang can catch back up to offer the rest of us a better choice.

Re:Thanks gcc! (4, Interesting)

serviscope_minor (664417) | more than 2 years ago | (#39446715)

But the key for any commercial entity is that clang beats the pants off any GPLv2-licensed compiler, and GPLv3-licensed code is pretty much irrelevant to most applications. So GCC is doing a great job for the insulated linux world, and hopefully clang can catch back up to offer the rest of us a better choice.

God, I hope not, I really do. I remember the bad old days, especially with embedded vendors. They would livense a perfectly good compiler front end and then fuck it up beyond repair. The resulting steaming heap of shit would crash half the time, and mysteriously not support random language features.

Ever since GCC took over the compiler world, my life has been much better.

Experience says that if you give vendors the chance to screw up a compiler in the name of "business" or "propretary" or whatever then they will.

Re:Thanks gcc! (5, Insightful)

KiloByte (825081) | more than 2 years ago | (#39446763)

How exactly GPLv3 on the _compiler_ stops you from doing anything? It has only one effect: ensures the toolchain stays usable for everyone.

Re:Thanks gcc! (5, Informative)

PaladinAlpha (645879) | more than 2 years ago | (#39446855)

Deliberate misinformation. You are free, of course, to do whatever you want to with binaries produced by GCC. GCC's license is completely irrelevant unless you're modifying or extending GCC itself.

Nice try, though.

Re:Thanks gcc! (-1, Troll)

aristedes (732532) | more than 2 years ago | (#39447069)

No, it is not as simple as this. The GCC GPL exceptions are quite complicated. Just outputting some intermediate builds from your computer (flicking a switch in the compile arguments) suddenly makes your entire proprietary product GPLv3. That is a very scary thought for any corporate legal department. http://www.gnu.org/licenses/gcc-exception-faq.html [gnu.org]

"Oh, you mean we accidentally released a GPL version of Microsoft Exchange server because of a toolchain change in our developer workflow. Oops...."

The FreeBSD project has already declined to upgrade its GCC implementation to the GPL version 3 release. That is one of the driving forces behind the move to clang/llvm within that community. So this really isn't quite so simple... The GPL v3 is quite scary to many corporations (as it was intended to be) and so they refuse to have anything GPLv3 installed on their machines at any level. I manage a 5 person development team and would always avoid anything GPLv3 without serious consideration of the implications.

Re:Thanks gcc! (5, Interesting)

PaladinAlpha (645879) | about 2 years ago | (#39447187)

This is just fearmongering. It's not complicated at all. If you don't hook GCC's (internal) intermediate code generation to run some custom process on, then you are covered by the compilation exemption.

Configuring your build to output GCC intermediate, retain that output, modify it with an external tool, and resume the build with the modified intermediate code is not something that will happen by accident. The implications of GCC being GPLv3 are, exactly, none.

FreeBSD's philosophical objections to GPLv3 are well known and they have the right to maintain those objections, but that has little bearing on GCC's use for a proprietary end product.

I would be interested to hear about your build process that you feel is likely to accidentally create a non-exempt compilation. Do you have an example?

Re:Thanks gcc! (5, Funny)

Anonymous Coward | about 2 years ago | (#39447319)

No because that would invalidate my unsubstantiated claim.

Re:Thanks gcc! (2, Informative)

Anonymous Coward | about 2 years ago | (#39447157)

clang never beat GCC. The benchmarks clang/LLVM originally published were run against an already old GCC version (by several releases). Thing is, GCC isn't a static target. It keeps getting better, and so far clang/LLVM hasn't been able to keep up.

Same thing with error messages. GCC has vastly improved error messages, now. clang's just look flashier because they use ANSI coloring.

The one place where clang/LLVM has actually managed to keep apace with GCC is in the complexity of the code. While GCC is a macro-filled horror show, clang/LLVM is an impenetrable mass of C++ casts, code generators (for clang, not for the LLVM engine), and other horrors. It's definitely not a showcase for how C++ can simplify development. It's somewhat easier to read, but is aging at an incredible pace.

And this comes from someone who uses clang all the time. I like both compilers, and I target both. Just like I make sure my code compiles cleanly on all the free BSDs as well as Linux.

Re:Thanks gcc! (0)

Anonymous Coward | more than 2 years ago | (#39446229)

Clang isn't complete. It doesn't compile all my software even if you refactor compiler specific code. I've been saying this for three years now but maybe it'll be ready next year.

Re:Thanks gcc! (5, Insightful)

msclrhd (1211086) | more than 2 years ago | (#39446263)

Having competing products (browsers, compilers, operating systems, ...) help keep those products from stagnating and help push all involved products to improving. It also helps prevent people being reliant on specific compiler/browser/office suite behaviour. GCC is not a "crap compiler", just like Firefox is not a "crap browser". That is not saying that GCC is issue free, nor that it has improved in part as a result from LLVM/Clang. Likewise, LLVM/Clang is not the panacea of compilers.

Competition on a level playing field is a good thing.

Re:Thanks gcc! (5, Interesting)

Anonymous Coward | more than 2 years ago | (#39446643)

Err... no?

Clang can be faster than GCC, when compiling with no optimizations. When you compile with optimizations enabled, that advantage disappears. Despite being nearly as slow as GCC with optimizations enabled, the binaries it produces are often slower. Some code (usually code that benefits from optimizations that Clang's developers could implement more easily than GCC's developers) may be slightly faster when compiled with Clang, but GCC's optimizer is far more mature than Clang's, and generally works better.

Error messages... Can't argue there. Modularity is pretty cool too, especially when you can built other tools on top of Clang that use Clang's parsers. Nothing stopping you from using those tools with another compiler though.

Clang's also not nearly as full-featured as GCC. Cross-compiling is a good example. Clang supports only a very limited number of architectures, and even with a supported architecture, cross-compilers are still kind of clumsy. Sure, GCC isn't perfect at this either, but you can use GCC to build code for virtually any platform that's still in use, and almost every platform that's been in use in the last 20 years, on nearly every operating system.

On most of the platforms GCC supports, it's by far the best compiler available. In some cases, it's the only compiler available. Even if the Clang developers wanted to support such a wide variety of platforms (they don't), it would take years to even approach GCC.

Even for things like C++11 support, GCC is still ahead. Despite Clang being apparently easier to develop (better architecture, or whatever), GCC has such a huge head start on Clang that it's managed to support far more of the new standard than Clang. It supports more of it than Microsoft's compiler too (which I gather has an architecture similar to Clang, but grew from an architecture that more closely resembles GCC).

Basically, Clang's a great compiler, but it's still very new. It's developed amazingly quickly, and I think it's going to be a fantastic compiler in a few years, but it's not quite there yet.

Always been? Hmmpf. (5, Funny)

bzzfzz (1542813) | more than 2 years ago | (#39445761)

Before GCC there were some excellent (for their day) compilers available from what was then an obscure technology company called Microsoft. There were cross-compilers for unusual platforms from Manx Software.

Kids these days. Next thing you know they'll think they invented sex.

Re:Always been? Hmmpf. (0)

Anonymous Coward | more than 2 years ago | (#39445895)

Yeah that Lattice C compiler was pretty good.

Re:Always been? Hmmpf. (1)

sensei moreh (868829) | about 2 years ago | (#39447113)

I remember Lattice C. I must be getting old.

Re:Always been? Hmmpf. (5, Informative)

fnj (64210) | more than 2 years ago | (#39446043)

Actually, while PC duffers were futzing with 16 bit Computer Innovations C, Lattice C, Microsoft C 1.0 in 1983, which was pretty much just a ripoff of Lattice C, then through the 80s with Microsoft C 2.0 through 6.0, with the first hesitant entry to 32 bits in 5.0 near the end of that period (even though there was no proper Microsoft 32 bit OS available yet at that time), REAL embedded programmers were working with 32 bit 68000, 68010, and 68020 using Green Hills C and compact deterministic real-time multi-tasking kernels such as VRTX.

Green Hills C was a significant improvement on the Portable C Compiler that came with SunOS and other BSD based unixes in those days.

When gcc finally matured, it was an ENORMOUS boon. The action nowadays is moving to Clang/LLVM though. With Clang, you don't have to compile a separate version for every cross-compile target. Every Clang executable is capable of producing code for any of the supported targets just by using the right run-time options. Of course, this doesn't address the point that you still need appropriate assemblers, linkers,libraries, startup code etc for each target. But they are trying to get a handle even on that with the Clang Universal Driver Project.

Re:Always been? Hmmpf. (4, Interesting)

samkass (174571) | more than 2 years ago | (#39446583)

Indeed, for most of gcc's existence I always saw it as a reasonable lowest-common-denominator compiler, not an especially good one. Up until about a decade ago, "cc" almost always beat "gcc" in performance on any given UNIX, but every "cc" was so different (especially if you dared throw C++ into the mix) you had to virtually port your code to each one. gcc was available for everything and had a reasonable percentage of the standard implemented so was where everyone gravitated towards. Since egcs merged back in and linux has gone more mainstream with Android variants it's gotten a lot more attention and is finally a pretty decent compiler.

Re:Always been? Hmmpf. (0)

Anonymous Coward | about 2 years ago | (#39447477)

The microsoft editor kicked ass in it's day. I think it was called m.exe . It originally shipped with the microsoft macro assembler which also kicks ass.

Really? (1)

broginator (1955750) | more than 2 years ago | (#39445769)

I'm older than gcc? Ugh, that can't be right... It just can't...

And showing every bit of its age too, apparently (0, Troll)

InterruptDescriptorT (531083) | more than 2 years ago | (#39445803)

I love GCC, don't get me wrong, but it seems to me from the research I've done that it's been left in the dust by Intel's and even Microsoft's compilers, which do a far better job at generating optimized code, especially for x86/x64. I have an application where I'd love to use GCC rather than a horrible vendor-specific C/C++ compiler to generate some ARM firmware, but I'm getting a lot of resistance due to its perceived poor/bloated code generation.

Can anyone confirm or deny this and make me at least able to justify GCC as a possible option again?

Re:And showing every bit of its age too, apparentl (0)

Anonymous Coward | more than 2 years ago | (#39445843)

Time to take it out back and shoot it.

Re:And showing every bit of its age too, apparentl (4, Insightful)

ichthus (72442) | more than 2 years ago | (#39445907)

Are you serious? You're a firmware engineer and you can't figure out what compiler to use. Further, you're developing for ARM and you think that Microsoft or Intel may be the best option?
<br><br>
NXP recommends GCC (Code Red IDE which is Eclipse-based), and ST recommends Keil, for their ARM micros. Just FYI.
<br><br>
Good luck on your school project.

Re:And showing every bit of its age too, apparentl (5, Funny)

Anonymous Coward | more than 2 years ago | (#39445941)

<br><br>

Good luck on your website.

Re:And showing every bit of its age too, apparentl (0)

Anonymous Coward | more than 2 years ago | (#39446605)

Laugh now, just wait until he's got a million Brazilian dollars.

Re:And showing every bit of its age too, apparentl (5, Insightful)

Anonymous Coward | more than 2 years ago | (#39445927)

Intel and Microsoft compilers are generally considered better than GCC for IA32 and x86_64, but that's mostly because those are the only platforms those compilers need to target (Microsoft care about ARM now, but I don't know how well MSVCC compares to GCC for any given ARM target). Architecture specific compilers will always be able to take crazy shortcuts in the optimiser and generator. GCC has to jump through all sorts of hoops between the front end and the back end, because the front end can't make any assumptions about the back end.

Re:And showing every bit of its age too, apparentl (0)

Anonymous Coward | more than 2 years ago | (#39445961)

Microsoft's compilers are specific to the Windows platform, while Intel's compilers are only free for non-commercial use. I don't think either company releases compiler source code. So depending on your situation they might not be an option.

Re:And showing every bit of its age too, apparentl (0)

Anonymous Coward | more than 2 years ago | (#39446013)

Well, one thing that's happened to me an awful lot is that GCC seems to generate smaller *and* faster code when using -Os rather than -O3. That it'd be smaller was no surprise to me, but the speed-up was. (For reference, I'm using an IA32 2 GHz CPU with 1.5 GB of RAM.)

Re:And showing every bit of its age too, apparentl (1, Insightful)

Tetsujin (103070) | more than 2 years ago | (#39446037)

Well, one thing that's happened to me an awful lot is that GCC seems to generate smaller *and* faster code when using -Os rather than -O3. That it'd be smaller was no surprise to me, but the speed-up was. (For reference, I'm using an IA32 2 GHz CPU with 1.5 GB of RAM.)

Fewer cache misses, maybe?

Re:And showing every bit of its age too, apparentl (0)

Anonymous Coward | more than 2 years ago | (#39446129)

If your program is largely compute-bound (small data) rather than memory-bound, smaller code can be faster because more of it fits in the L1 instruction cache.

Re:And showing every bit of its age too, apparentl (1)

Bert64 (520050) | more than 2 years ago | (#39446433)

Depends largely on the size of your cpu cache, although i was pretty sure gcc (or maybe it was some other compiler) had some options to take cache sizes and relative performance of different level caches vs ram into account when generating optimized code.

Re:And showing every bit of its age too, apparentl (2, Interesting)

fast turtle (1118037) | more than 2 years ago | (#39446685)

RTFM idiot - Os means to optimize for size. The generally accepted standard flag for GCC is -O2 as it's the best compromise between Size and speed up. The only thing is, Sped Up is dependent upon various elements within the source code such as loops and CPU specific options as we Gentoo users tested. Some apps actually do well with O3 flag, most work fine with O2 and from my experience, Os offered the best performance with smallest size possible from the binaries. Most of the speed increases come from fewer cache misses as the binaries are sometimes small enough to actually fit within the L2-L3 cache when the cpu has sufficient space.

Re:And showing every bit of its age too, apparentl (0, Troll)

beelsebob (529313) | more than 2 years ago | (#39446099)

It's not just been left in the dust by Intel and MS's – it's also been left in the dust by Apple's (now BSDed) clang [llvm.org] . It runs faster, produces faster code, produces better error messages, is more amenable for using parts in other tools, has a brilliant static analysis tool that comes with it, ...

Re:And showing every bit of its age too, apparentl (2)

micheas (231635) | about 2 years ago | (#39447159)

Unless of course clang generates code that is twice as slow as gcc

SmallPT [kevinbeason.com] is one graphics program that seems to be much slower with clang than gcc.

Re:And showing every bit of its age too, apparentl (1)

gl4ss (559668) | more than 2 years ago | (#39446163)

fuck perceived. show that it works, people will then agree to use it.

I'd reckon a bigger problem is codebases made to compile on specific hard to get versions of say.. arm rvtc.

if the problem for using gcc is just perceived bloat in binaries you're in heaven, stfu and eat cookies.

Re:And showing every bit of its age too, apparentl (1)

rhysweatherley (193588) | more than 2 years ago | (#39446249)

If you need a compiler with special optimization options to make your code run fast, then either your algorithm or your data structure is wrong. Implicitly-parallel SIMD problems are a notable exception - same operation on massive amount of data. Everything else is PEBKAC.

Happy birthday gcc - making me think more carefully and write better code for 25 years!

beg to differ (3, Informative)

Chirs (87576) | more than 2 years ago | (#39446527)

You can have the best algorithm in the world, and a good compiler will *still* be able to make it run faster than a bad one.

Alignment, branch probabilities, inline functions, hoisting stuff out of loops, loop unrolling, removing unused code, etc.--these sorts of things really can make a difference in code that gets called frequently.

That said, it's not exactly clear that the Intel compiler (icc) is unconditionally better than gcc. There are some benchmarks at http://www.linuxforge.net/docs/bm/bench-gcc-icc.php [linuxforge.net] of a linux-2.6.34 kernel compiled with gcc and icc. The results are close enough that it doesn't make sense for most people to use icc.

Re:And showing every bit of its age too, apparentl (0)

DCFusor (1763438) | more than 2 years ago | (#39446333)

Intel's and microsoft's compilers only handle x86, though. GCC can compile for a rather larger variety of targets...

Re:And showing every bit of its age too, apparentl (3, Interesting)

phantomfive (622387) | more than 2 years ago | (#39447031)

If you're programming in C, which is very likely if you're doing embedded, you're going to hate your life if you have to use Microsoft's compiler. It doesn't support C99 very well (at all?), it doesn't allow inline functions, forces you to declare all your variables at the top of a function, and a number of other annoying things that I only remember when I have to use it.

Basically stay away from Microsoft compiler for C if you can help it.

Re:And showing every bit of its age too, apparentl (1)

jonwil (467024) | about 2 years ago | (#39447295)

Is GCC on Windows still treated like a third-class citizen? I remember a resistance to supporting certain features of Windows that the MS computer supported like SEH but I dont know if that has changed.

Happy Birthday! (2)

go_epsilon_go (802226) | more than 2 years ago | (#39445825)

Happy Birthday gcc!

And now it's time to bow out gracefully (-1, Troll)

chrism238 (657741) | more than 2 years ago | (#39445835)

Thank you gcc - you've served so many of us, so very well. But now it's time to bow out gracefully, as we turn towards Clang and LLVM.

Re:And now it's time to bow out gracefully (0)

Anonymous Coward | more than 2 years ago | (#39445893)

If you want to use LLVM then use it. If it's really better then GCC will eventually fall out of development naturally. No need to try and force things to go your way by demanding that GCC just give up.

Re:And now it's time to bow out gracefully (0)

Anonymous Coward | more than 2 years ago | (#39446291)

Let's see how well Clang and LLVM do once they support the number of architectures that GCC does, shall we?

Happy birthday (2)

Sav1or (2600417) | more than 2 years ago | (#39445935)

Yay for gcc, always giving me errors and making me actually try to get it right the first time.

Tor FUCKED me in the ASS!! Vidalia DATA DEBUG DUMP (-1)

Anonymous Coward | more than 2 years ago | (#39445967)

#
                  Tor Browser Bundle for Linux (2.2.35-8) "EVIL bug"
                                                  *** NEVER FORGET ***
#
- http://seclists.org/bugtraq/2012/Mar/85 [seclists.org]
- http://www.securityfocus.com/archive/1/522003/30/0/threaded [securityfocus.com]
#
"There is an EVIL bug in at least the Linux (2.2.35-8) Tor Browser Bundle start-tor-browser script. It will log things
like domain names to a file in the root of the browser bundle."

https://trac.torproject.org/projects/tor/ticket/5417 [torproject.org]

Ticket #5417 (new defect)

RelativeLink.sh in Tor browser bundle has small typo causing debug mode to be always turned on

Reported by: cypherpunks
Priority: critical
Component: Tor bundles/installation

Description

TBB starts in debug mode disregardless of --debug switch used or not. This is caused by small bug on line 208 on
RelativeLink.sh, where it says

if [ "${debug}" ];

where it should say

if [ "${debug}" == 1];

or

if [ ${debug} -eq 1 ];

#
Thank you for the warning. I expected something like this to happen, given the last slip up with a mistake in FF versions. This, "error", if you wish to call it such, shouldn't have happened. Again, this is a lack of testing.

I hope no one in Iran, China, or other freedom starved regions were screwed because of this.

I hope a fix is released and quickly.

These mistakes should be posted in the Tor announcements mailing list (no announcements at all since Dec/11 is pathetic) and on the blog.

It would help Tor users even more if you were to actually create web forums for discussions (but I doubt you will, we've only been asking for this for years!) where you could sticky-pin these types of mistakes and communicate better with the broad range of users.

A large number of people will never use a bug tracker, and/or never use mailing lists. They are simpler minded people or too busy, this is where web based discussion forums come in. Users should not have to scramble to unofficial .onion forums which are up one day and down the next and which may (and have in the past!) contain malicious posts/threads to target the user's browser and/or Tor itself.

With errors like this, perhaps you should let Mickey Mouse sign the future Linux release bundles with his fictional GPG key. He couldn't do any worse.

I've also noticed FF crashing more often since the last few releases.

I guess it's time for us Linux bundle users to run W.I.N.E. and the Windows version of the bundle on Linux so we know we are not getting borked with some new fantastic bug or lack of oversight like this again.

But will this post be approved for others to see, or swept under the rug like one previous post about a similar issue.

Now I'm looking forward to the next release, not for use, but just to see what type of bug(s) it may contain. THANKS!

#
Nick Mathewson
Mon, 19 Mar 2012 09:40:43 -0700

It seems that a fix was merged yesterday: see
https://trac.torproject.org/projects/tor/ticket/5417 [torproject.org] and
https://lists.torproject.org/pipermail/tor-commits/2012-March/041036.html [torproject.org]
.

I bet there will be new TBBs out very soon.

In the meantime, Linux users should delete vidalia-debug-log and
symlink it to /dev/null. (Haven't tested that, but it should work:

    % ln -sf /dev/null /path/to/vidalia-debug-log
    % ls -l /path/to/vidalia-debug-log

    lrwxr-xr-x 1 username username 9 Mar 19 11:53 vidalia-debug-log
-> /dev/null .)

IMO, this is a really good reason for us to move to getting enough
automation done so we can have nightly TBB builds and catch this kind
of thing *before* actual releases come out.

--
Nick
#
Sebastian Hahn
Tue, 20 Mar 2012 02:20:08 -0700

The bug in TBB is quite severe, and it is against its stated goals and
design principles (one of which is leaving no/as little traces as
possible on disk for later forensics). This bug was severe, it was fixed
quickly, and hopefully nobody was impacted too much. Time to move on.
#
Read and archive these also (to record history for this "EVIL bug":

https://lists.torproject.org/pipermail/tor-commits/2012-March/040941.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040942.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040939.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040945.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040950.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040952.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/040953.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041036.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041037.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041038.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041039.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041040.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041043.html [torproject.org]
https://lists.torproject.org/pipermail/tor-commits/2012-March/041056.html [torproject.org]
#
History won't recall this bug and the severity of it unless you
archive this information and the information at the links issued
above.

DON'T LET YOURSELF GET FUCKED IN THE ASS BY VIDALIA DEBUG DUMPING ALL OF YOUR DATA IN REAL TIME! BE WARNED ON FUTURE VERSIONS OF TOR BROWSER BUNDLE

DeSmet C (1)

willoughby (1367773) | more than 2 years ago | (#39446007)

I still miss putzing around with the compiler from Rick DeSmet to communicate with my dot-matrix printer trying to get it to change fonts. The GCC is a remarkable achievement, and important, but my fondest memories are elsewhere.

OH GOD HELP ME (0, Funny)

Anonymous Coward | more than 2 years ago | (#39446025)

Maybe this is a good place to turn to for help. I have a C assignment that's due this week, and I can't figure it out!

How do I output a string without outputting in the end of line at the end?!

Like if I have an char firstname[5] that has "Bob\0\0", both printf() and puts() will put a newline at the end. How do I get it so it doesn't insert a newline, so I can output "Bob was here" in one line?

Help me Slashdot, you're my only hope!

Re:OH GOD HELP ME (0)

Anonymous Coward | more than 2 years ago | (#39446281)

Like if I have an char firstname[5] that has "Bob\0\0", both printf() and puts() will put a newline at the end.

No they won't

Re:OH GOD HELP ME (0)

Anonymous Coward | more than 2 years ago | (#39446397)

for (i = 0; i < 5; i++) putc(firstname[i]);

Re:OH GOD HELP ME (1)

Anonymous Coward | more than 2 years ago | (#39447019)

exit(EXIT_FAILURE);

Re:OH GOD HELP ME (0)

Anonymous Coward | about 2 years ago | (#39447281)

Printf will not output a newline unless you tell it to.

You want:

char *firstname="Bob";
printf("%s", firstname);
printf("Bob");

To print with newline:

pintf("%s\n", firstname);
priintf("Bob\n");

Reminiscing (1)

MichaelJ (140077) | more than 2 years ago | (#39446177)

The best part of the entire linked-to page was the email addressing at the bottom of the announcement. UUCP paths. Those truly were the days.

Re:Reminiscing (0)

Anonymous Coward | about 2 years ago | (#39447217)

Google Groups losing information--

Click on the link in the original summary to see the announcement from 1987:
    http://groups.google.com/group/mod.compilers/msg/1b3f30d88eab88f8?pli=1 [google.com]

Then click on the link at the top from Google:
    The old Google Groups will be going away soon. Switch to the new Google Groups.

When I switch, the poster's handle "johnl" is removed in the "new" version and is replaced with (unknown)

Hey Googlers, remember, "Don't be evil!"

Cool story bro! (0)

Anonymous Coward | more than 2 years ago | (#39446347)

I turn 25 this week too!

Re:Cool story bro! (0)

Anonymous Coward | more than 2 years ago | (#39446705)

Off to the carousel with you, then.

Thank you gnu (5, Insightful)

Ada_Rules (260218) | more than 2 years ago | (#39446765)

I remember the first time I built gcc in college on an decstation (probably around 1990) I was thrilled to have a free compiler with source code. It almost seemed like magic. Several years later when the GNAT project started and promised to bring Ada programming to GCC I was even happier but I never really expected it would turn into the high quality Ada compiler that we have today. While HURD never really worked out, the GCC project alone (never mind the vast quantity of other software covered by the GPL) has been transformational and I think many of the younger generation take the existence of this stuff for granted.

Now, get off my lawn.

My admiration... (0)

Anonymous Coward | more than 2 years ago | (#39446917)

My admiration belongs with Gimple?

No, my admiration for GCC today is for it's political and open source community contribution.

But technically, I've come to find GCC to be a very obtuse and difficult tool to nurse through my current projects.

I'll always admire and defend GCC as an industry changing tool, but if I'm honest, it's not my day-to-day compiler of choice any longer.

But regardless, Long live GCC.

Theodore Ts'o yay (5, Interesting)

brainiac (90448) | about 2 years ago | (#39447315)

Linux started on usenet, and what really made it blow up was the ability to use gcc to write software. The first version of linux everyone was running didn't have a login, you just got root. Soon the login program came, (i think getty). But anyway it was Theodore Ts'o who did the heavy lifting. Every new program needed something new in the C library and Theodore somehow got it done.

Thanks Theodore !!

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?