GCC 4.9 Coming With Big New Features

jones_supa writes "When GCC 4.9 is released in 2014 it will be coming in hot on new features with a large assortment of improvements and new functionality for the open-source compiler. Phoronix provides a recap of some of the really great features of this next major compiler release from the Free Software Foundation. For a quick list: OpenMP 4.0, Intel Cilk Plus multi-threading support, Intel Bay Trail and Silvermont support, NDS32 port, Undefined Behavior Sanitizer, Address Sanitizer, ADA and Fortran updates, improved C11 / C++11 / C++14, better x86 intrinsics, refined diagnostics output. Bubbling under are still: Bulldozer 4 / Excavator support, OpenACC, JIT compiler, disabling Java by default."

Comments

frist

[Anonymous Coward]

finally

Re:frist

[Anonymous Coward]

It is his resumé.

Re:frist

[StripedCow]

finally

C++0x does not have "finally".
You'll have to implement it yourself, e.g. using a destructor.
See for example: http://codereview.stackexchange.com/questions/2864/an-implementation-of-finally-in-c0x

A big improvement indeed

[Anonymous Coward]

New in this release: lots of stuff most people don't care about, some minor improvements and oh yeah we gave up on Java.

Re:A big improvement indeed

[symes]

I have to agree - I've been trying to find out more on the multi-threading support, something that is strangely lacking detail but you would imagine could be quite popular

Re:A big improvement indeed

[Joce640k]

we gave up on Java.

That's not news?

Re:A big improvement indeed

[cduffy]

You only don't care about sanitizing standard-undefined behavior if you don't care about bugs.

That one's a Really, Really Big Deal.

Re:A big improvement indeed

[Anonymous Coward]

What exactly you needed to find out? it supports perfectly well multithreading for output programs and for itself.
What is more interesting - MP, GPGPU technology...

Re:A big improvement indeed

[Anonymous Coward]

New in this release: [...] we gave up on Java.

Well, actually it's the other way around: Java gave up on them - meaning that actual development of GCJ moved from GCC to OpenJDK.
Not that i understand what it means for GCC, but i understand that it does not mean much for Java.

Re:A big improvement indeed

[Anonymous Coward]

lots of stuff most people don't care about

Personally I do care about Address Sanitizer and UB Sanitizer. This is one of the most useful features of clang that gcc lacks.

All others features probably will not affect most of the users, but at least they prevent statements like "I can't compile my program with gcc, because it doesn't support X".

Re:A big improvement indeed

[Anonymous Coward]

One thing gcc allows is to compile Java code into native code. Is this also supported by OpenJDK?

Re:A big improvement indeed

[DuckDodgers]

No, it is not. But GCJ Java-to-native compiling didn't result in particularly fast Java code. That's one of the major reasons developers and enterprises ignored GCJ in the first place.

Re:A big improvement indeed

[Anonymous Coward]

You only care about it if you have written code that is walks slap bang into undefined behavior. The compiler is the least of your problems.

Re:A big improvement indeed

[larry bagina]

I care. Or I will, in 5 years, when it's finally available in debian.

Re:A big improvement indeed

[Hizonner]

I assume you can list all the undefined behaviors in the C standard off the top of your head, yes? And you've never actually written a line of code with an error in it, right?

I've spent a lot of time cleaning up after security bugs written by people with that attitude. None of them could make mistakes either. Maybe you guys should form a club, so the rest of us can identify the special beings walking among us.

Re:A big improvement indeed

[turgid]

+1 Hear, hear.

Re:A big improvement indeed

[Anonymous Coward]

You only care about it if you have written code that is walks slap bang into undefined behavior.

Which happens when you don't care about it.

Re:A big improvement indeed

[Anonymous Coward]

Did you know that the following is now undefined behaviors thanks to GCC's adherence to the strict aliasing rule?

void *get_in_addr( struct sockaddr *sa ) {
    if (sa->sa_family == AF_INET)
        return &(((struct sockaddr_in*)sa)->sin_addr);
    else
        return &(((struct sockaddr_in6*)sa)->sin6_addr);
}

So yeah. Suck on it.

Re:A big improvement indeed

[StripedCow]

That whole sockaddr design sucks. It's about time somebody (or some compiler) complained about it.

Re:A big improvement indeed

[Anonymous Coward]

A big advantage of gcj is that the resulting binaries start a lot faster than firing up a 'normal' jre. If you have a 'simple' program, that you only need a few times a day, compiling it with gcj may be a really efficient way to run it.

Re:A big improvement indeed

[Anonymous Coward]

not sure giving up on java is that big a deal with openjdk.. in fact this is probably a smart decision, why repeat the effort when we don't have to there are so many more things to focus on :P)

Re:A big improvement indeed

[serviscope_minor]

Did you know that the following is now undefined behaviors thanks to GCC's adherence to the strict aliasing rule?

Surely that depends on the design of sockaddr. If the first member is a union of sockaddr_in and sockaddr_in6, then I think it will work. You can certainly cast a pointer to a struct to a pointer to the first member. And, you can certainly cast a pointer to a union to a pointer to any member. No idea if you can do both in one operation.

Either way the fact that this is not obvious does indeed illustrate the utility of an undefined behaviour sanitizer. I for one welcome it.

Re:A big improvement indeed

[Anonymous Coward]

Really? A lot off applications will break if that kind of code does not compile correctly. Perhaps we have to wait with popcorns ready until mr Torvalds meets this feature;)

Re:A big improvement indeed

[Anonymous Coward]

It already was undefined behaviour since the standard introduced the strict aliasing rule. It's just that compilers didn't take advantage of it. Anyway, I doubt that gcc removed the flag -fno-strict-aliasing. So if you need to write such code, just add that flag. It's not that hard, is it?

Re:A big improvement indeed

[aaaaaaargh!]

Where do such negative comments come from? Have programers generally left /.? :-/

I for one welcome gcc 4.9, as it allows me to use the full Ada 2012 language. Good job!

Re:A big improvement indeed

[cheesybagel]

IMO the problem is the lack of a JIT compiler. Java is too slow without it.

Re:A big improvement indeed

[ConceptJunkie]

Agreed. It's not the 1970s any more. We can adopt a design that reflects this fact.

Re:A big improvement indeed

[blueg3]

If you don't care about safety and error checking, multithreading, Atom SoCs, or C++11... what sort of new features are you really expecting in a compiler. That touches pretty much all the major functionality of a compiler.

Re:A big improvement indeed

[Anonymous Coward]

Not really.
They are just disabling java in the default build because it adds 15 minutes to the compile time, and no one uses it.

Re:A big improvement indeed

[alex67500]

No it's a relief. Hopefully Sun will follow suit soon...

Re:A big improvement indeed

[Anonymous Coward]

You can still build gcj. It's just not being built any more every single time you compile gcc.

Re:A big improvement indeed

[Anonymous Coward]

Frankly I neither know nor care if your perception is that you have spent a lot of time cleaning up after security bugs, but the fact that you don't understood what my attitude is makes it fairly implausible.

For one thing, a lot of shops do not permit a drop into naked API calls, and areas of concern are often abstracted out. And even if they a developer and tests should be checking the documentation for that API. But that's all irrelevant. My point was that this is mainly useful on programs that already have flaws that should not be waiting either for Your Highness or gcc 4.9 to percolate into all of the used OSs.

If a bleeding edge compiler release is relevant to your security NOW you have problems.

Re:A big improvement indeed

[Anonymous Coward]

The JIT is mostly necessary since javac has no information about what classes are loaded at runtime. GCJ has more information and could have done a lot of escape analysis, inlining, etc.. The problem gcj had was lack of interested developers good enough to implement these optimisations.

Re:A big improvement indeed

[Anonymous Coward]

No, it is not. But GCJ Java-to-native compiling didn't result in particularly fast Java code. That's one of the major reasons developers and enterprises ignored GCJ in the first place.

That's interesting. I've always wondered how much of the speed difference between Java and C++ is due to using a JVM instead of a binary, and how much is due to the differences between the languages. Was there not enough work on making gcj produce fast code, or does this show that it's the language rather than the execution environment that's responsible for most of the speed difference?

Re:A big improvement indeed

[Anonymous Coward]

The point is not that you can't make it work, but that too many people fail to realize that such simple code can amount to undefined behavior. And of those that know better, it is still possible to make an aliasing mistake when working with code that you are trying to make work with proper rules. You can't say, "Well, just write code that doesn't bump into undefined behavior." You might as well say, "Well, just write code that doesn't have any bugs... so why should we care about improvements in debuggers?"

Re:A big improvement indeed

[Anonymous Coward]

> Maybe you guys should form a club, so the rest of us can identify the special beings walking among us.

http://www.openbsd.org

there you go.

Re:A big improvement indeed

[lgw]

C++11 added threading constructs to the standard library, and I believe C++14 has some minor changes there as well. Standard cross-platform multi-threading is a big deal, though it's had to find documentation on the details.

I just discovered that thread-local storage is now a standard library thing - which is awesome. TLS is quite useful for logging and other infrastructure stuff, and making it standard is quite welcome.

Re:A big improvement indeed

[Anonymous Coward]

Uh, Sun gave up on everything already.

Re:A big improvement indeed

[Anonymous Coward]

Sadly, C's mutexes are limited by what Windows can provide. On Windows all mutexes need to be initialized before use. In C++ this isn't a problem because you can define load-time constructors. In C there's no standard way to do this, so C mutexes must be explicitly initialized at run-time, which is a needless headache, especially in libraries which try to be opaque.

POSIX mutexes can be initialized at compile time, which is far saner.

Re:A big improvement indeed

[Anonymous Coward]

That's not undefined behavior. It'd only be undefined behavior once you dereference the pointer to a struct s_addr or struct s6_addr object. And then, in practice, GCC would only complain if you did it in the same routine.

And you could always use memcpy to copy the object into a non-type-punned object in order to access the value, so the above code is perfectly useful, although you might want to also return a size_t object as an out-parameter so you can copy the data into a union object.

Now that GCC and clang complain about these things more, doubtless they'll offer annotations which system headers can use to tell the compiler to shut-up. Too bad the C standard didn't provide any such annotations.

Re:A big improvement indeed

[Darinbob]

I don't know, some looks interesting. I'd like to get the sanitizers for extra code checking during compile instead of waiting for an external lengthy static analysis tool.

Re:A big improvement indeed

[Darinbob]

No one programs anymore. All we do is link together pre-built libraries and frameworks and wrap it all in XML. Not sure who actually codes those libraries or where they come from, but the prevailing theory is that once a year the senior developers hike to the top of Mount Olympus and wrestle them away from the gods.

Re:A big improvement indeed

[lgw]

What, really? I had no idea gcc did Ada - that's actually pretty cool.

Re:A big improvement indeed

[lgw]

On Windows, you use critical sections, not mutexes, for most things. Perhaps the biggest design mistake in all of win32 was that need to initialize them (and setting the memory to all 0, which at least in C++ you can count on in many cases, isn't right). It's a huge "what where they thinking?".

How is anything "initialized" at compile time in C? Or do you mean that clearing the memory to 0 is correct for initializing a POSIX mutex?

Re:A big improvement indeed

[HiThere]

You don't need to wait for gcc to include the latest version of gnat. It's available for download from AdaCore http://libre.adacore.com/ in either GPL or commercially supported forms. (Commercial support is intended for companies, though, not for developers. It's a slightly different version, but pretty much the same. And it comes with official support. But it's just a mite expensive. )

Re:A big improvement indeed

[david_thornley]

You are entirely correct: this is only applicable to code with bugs (sometimes obscure ones). Therefore, as you point out, it is mostly useless, since it is only of use to people who write buggy software and/or haven't memorized every source of undefined behavior in the appropriate Standard. The vast majority of programmers who have memorized the Standards and never write bugs have no need for it.

Re:A big improvement indeed

[Anonymous Coward]

... and what have you contributed lately?

Re:A big improvement indeed

[Jorl17]

A POSIX mutex can be initialized via a call to a library function or, alternatively, it can be "statically initialized" with the constant value of PTHREAD_MUTEX_INITIALIZER, which initializes it and sets default attributes. It's not exactly "clearing the memory to 0", but it's along the lines of that train of thought

Re:A big improvement indeed

[charles2678]

My point was that this is mainly useful on programs that already have flaws

How many programs don't?

I strongly recommend reading (or at least doing a quick pass over) http://pdos.csail.mit.edu/papers/ub:apsys12.pdf to get an idea of the scope of the problem.

Re:A big improvement indeed

[aaaaaaargh!]

The AdaCore libre version doesn't allow you to distribute your executables under non-GPL license. You'd have to buy the super-expensive pro version instead. The FSF version of Gnat, on the other hand, does allow you to distribute your executables under any license you like because it comes under the Gnat Modified GPL (GMGPL).

That's why I wait. :-)

Re:A big improvement indeed

[lgw]

Ah, got it - that works for C, but isn't as good for C++.

I say this having personally fought a bug in production C++ code where control entered a critical section during static initialization, before the compiler's arbitrary initialization order initialized the critical section, leaving the object in a busted state for runtime and causing the most bizarre and cryptic deadlocks. But C++ wipes everything static to 0 before it plays any games, and all my personal code is designed where that is proper initialization (wherever practical).

Re:A big improvement indeed

[Anonymous Coward]

Anti-capitalism? You say that like it's a bad thing.

Re:A big improvement indeed

[Anonymous Coward]

It's irrelevant to those components that do not use naked C API calls and instead have internal frameworks and idiomatic usage that restricts the unsafe portions to extremely well vetted components.

Re:A big improvement indeed

[charles2678]

It's irrelevant to those components that do not use naked C API calls

Utterly untrue. This is about language ambiguity, not standard library ambiguity, so the C language API is moot.

Improved diagnostics output

[Anonymous Coward]

Improved diagnostics output. GCC can now play with colors!

Maybe not..
This is just noise.

Re:Improved diagnostics output

[Anonymous Coward]

Pretty colors are for the clang kids who only know how to code with crayons and finger paints.

Re:Improved diagnostics output

[Anonymous Coward]

Pretty colors are for the clang kids who only know how to code with crayons and finger paints.

I was writing a kernel once, but then I ran out of blue crayon and had to drop it. :-(

Blue finger paint just isn't good enough!

Re:Improved diagnostics output

[binarylarry]

Blue finger paints is crap.

- Linus

ADA?

[Black Parrot]

"Ada" is the name of a person, and the language.

"ADA" is the Americans with Disabilities Act, or the American Dental Association.

Re:ADA?

[Bozzio]

"ADA" is the Americans with Disabilities Act, or the American Dental Association.

... and quite a few other things, if you care to look outside of the US: http://en.wikipedia.org/wiki/ADA

Re:ADA?

[HiThere]

And within the US it's at least the American Dental Association. Probably also several others. TLAs are highly overloaded.

Re:ADA?

[antdude]

I hope it is "Americans with Disabilities Act" since I am disabled. ;)

Can we please stop mass-linking Phoronix?

[Anonymous Coward]

For God's sake, that's *THIRTEEN* (13) links to Phoronix!
Pointing to a couple of ML threads or to the 4.9 changelog would've been more than enough. http://gcc.gnu.org/gcc-4.9/changes.html

Re:Can we please stop mass-linking Phoronix?

[Anonymous Coward]

Self-linking is the modus operandi of Phoronix. It is a link farm, after all.

All you will get is a mass of links, whether you click through to TFA or not. At least this way there's no utility in clicking through.

Re:Can we please stop mass-linking Phoronix?

[Ant P.]

I understand the frustration, but that site *wants* to be populated entirely by the kind of morons that fall for blatant SEO spam. Smart people wouldn't make them money via pay-per-impression ad sandbagging, after all.

Coming in 1024 sometime?

[John.Banister]

This is like Amazon book ads, only more pointless. Why not either make a submission "The GCC team needs your donation," or wait to advertise it until people can respond to the ad and download it? If it had only one new feature (and it wasn't "now secretly adds more sophisticated backdoors") people with any sort of interest in using GCC will probably get the new version when it's available.

Re:Coming in 1024 sometime?

[Greyfox]

2014 is just a month and a half away, and you can compile 4.9 now from the dev branch of their subversion tree.

Re:Coming in 1024 sometime?

[John.Banister]

"Coming January 1st 2014, and here's a link where you can compile it now" would make the above announcement come across as more relevant to the present.

Looks like they are porting Clang features...

[gnasher719]

The whole article really reads quite fanboyish / alternatively GCC has hired a marketing department. But it looks really lame when you talk about exiting new features, and you just copied what Clang had before.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Superior backend, coming up to par with Clang on the frontend, what's not to love?

Frankly, the BSD licenses appear to be a failure psychologically. The proponents of BSD-licensed software go apeshit when GPL-licensed software reuses their code, but are ok if the stuff disappears in proprietary forks.

You can see this, for example, with LibreOffice/OpenOffice: every LibreOffice release announcement draws ire from the OpenOffice crowd (well, particularly one OpenOffice developer) because the latter feels their code has been ripped off.

There has been a lot of that going on with OpenBSD and FreeBSD as well, but it's grown a bit more quiet in recent years.

Now we have the same with Clang/GCC.

If you don't want to have your code relicensed under different licenses, use a Copyleft license. If you want to have your code relicensed under different licenses, stop complaining when somebody actually does exactly that.

Re:Looks like they are porting Clang features...

[mvdwege]

Wait, what, Clang now supports other languages than C-derivatives, like Ada and Fortran?

Re:Looks like they are porting Clang features...

[Anonymous Coward]

But it looks really lame when you talk about exiting new features, and you just copied what Clang had before.

Might be true. But also shows that competition is healthy. If clang wasn't there to implement these features first, GCC wouldn't have done it as well, maybe. So I think: everyone wins.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Yep. They're also stealing OMP4.0 from Clang (which got OMP3.1 just a month or so ago, while GCC had it since 4.7) and Cilk (which is not in Clang at all, though people are working on 3rd party extension)

The whole post really reads quite trollish / alternatively Clang has hired black PR department.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

> Frankly, the BSD licenses appear to be a failure psychologically. The proponents of BSD-licensed software go apeshit when GPL-licensed software reuses their code, but are ok if the stuff disappears in proprietary forks.

It's mostly Theo de Raadt, not the "OpenBSD community" Theo likes to take credit for a lot of work that, frankly, he and the OpenBSD community did not do but which has slipped under the OpenBSD umbrella. Take a look at the original SSH code and how it gor reliensed by OpenBSD. It's frankly the only useful tool coming from that community, and they *STILL* keep the user and host private keys in unencrypted plain text, with no passphrase, by default and no expiration date, and no usable chroot cage. (The SFTP chroot cage setup is a joke, and a sad one.)

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Yup. Remember the "OMG they're stealing our code!" whinefest when a linux dev copied the juicy parts of a BSD wifi driver?

Re:Looks like they are porting Clang features...

[Anonymous Coward]

The problem with code re-usage to GPL projects is that it is so much more complicated to copy features back.
If a proprietary project with closed source uses the BSD licensed project but add nifty functions it is just a matter of writing similar functions of your own.
When a GNU licensed project grabs some BSD code and improves upon you can't just write code that does the same, because if you do then it is very likely that your code will end up looking very much like the GNU licensed implementation and people will find it less plausible that you didn't look at the other source.

Also, it is pretty clear that the intention of BSD licensed code is to have an open source project that is free to use. While grabbing it and releasing it under a less free open source license is completely legal it is clearly a dickish move. Anyone who isn't a zealot would just add their changes under the original license to honor the intentions of the original author.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

The proponents of BSD-licensed software go apeshit when GPL-licensed software reuses their code

Do you have some links? I've been hearing this for years, but I've never seen it happen.
Actually, I've always had the impression BSD developers were happy about their code being reused by anyone (why would they use such a license otherwise?).

If you don't want to have your code relicensed under different licenses, use a Copyleft license

Permissive licenses don't let you relicense the code under a different license either.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Wasn't that because the Linux dev changed the license of the code? That's illegal and once fixed I don't remember anyone complaining.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

It's hard to take your claim seriously when your only evidence is a single guy with a stick up his ass. As far as I can tell, there is a place for both open source licenses (BSD and GPL), and the people who actually use those licenses normally get along fine.

You're going to have to do a lot more hand-waving than that.

Re:Looks like they are porting Clang features...

[Bengie]

You can see this, for example, with LibreOffice/OpenOffice: every LibreOffice release announcement draws ire from the OpenOffice crowd (well, particularly one OpenOffice developer) because the latter feels their code has been ripped off.

What? These are both GPL. I've never seen BSD people care at all about who uses their code, only GPL people freaking out. How did this hogwash get voted up?

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Permissive licenses don't let you relicense the code under a different license either.

What about CC0?

Re:Looks like they are porting Clang features...

[DuckDodgers]

You are re-stating the original argument about free software that has been done to death on the internet.

To the BSD folks, they want to write software that is free as in free beer. You can take it, and do whatever you want with it. Drink it, dump it in the trash, give it to your friends, sell it. Free as in Freedom of the user

To the GPL or Free Software Foundation folks, they want to write software that is free as in free speech. You can copy it, and distribute it, but you can't restrict other people's rights to copy it and distribute it. Just like I can't hand out a copy of the US Constitution or a speech by Abraham Lincoln and forbid other people from sharing it or publishing a copy. Free as in Freedom of the software

You may prefer the BSD way, and that's fine, but "who isn't a zealot" is out of line. Having a different set of priorities does not make one a dick. Blatantly copying code under one license to the other is a dickish move, but re-engineering from one to the other is perfectly legitimate. And yes, I'm in the FSF camp.

Re: Looks like they are porting Clang features...

[Anonymous Coward]

I have zero respect for people not using gcc for compiling programs because of its license. They are either ignorant, or zealots, or both.

Note that things are completely different if you want to actually integrate compiler code into your project; in that case of course the license matters.

Re:Looks like they are porting Clang features...

[peppepz]

The difference between the BSD license and the GPL is that it allows you to copy the code and use it under more restrictive terms. You're saying that however, if you do, then you're a zealot. So what's the advantage of the BSD license, if the GPL only harms zealots?

If a proprietary project with closed source uses the BSD licensed project but add nifty functions it is just a matter of writing similar functions of your own. When a GNU licensed project grabs some BSD code and improves upon you can't just write code that does the same, because if you do then it is very likely that your code will end up looking very much like the GNU licensed implementation and people will find it less plausible that you didn't look at the other source.

What's the difference? If you didn't look at the original code, then the chances that your own code will look very much like the invisible implementation are the same, whether that invisible implementation is GNU or proprietary. If you did look at the original code, then you're deriving from it, and you should respect its license.

Re: Looks like they are porting Clang features...

[Anonymous Coward]

I have zero respect for people using gcc for compiling programs because of its license. They are either ignorant, or zealots, or both.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

INAL, but no. The would defeat its entire purpose.

You can incorporate a CC0 work into a differently licensed one, but you can't change the license of the original.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Wasn't that because the Linux dev changed the license of the code? That's illegal

No, it isn't. That's one of the points of (modified) BSD.

and once fixed I don't remember anyone complaining.

I have not followed this, but my guess would be that the original attributions/authorship notices were removed in the source code. And that's pretty much the only thing that BSD/MIT licensing actually insists on. But that is not the background behind the majority of shit storms.

Re: Looks like they are porting Clang features...

[turgid]

Not in this case. my hardcore development has all moved to clang. we dumped GCC like the gpl-infested crap hole that it is.

Was that so that you could add your own proprietary language front-end and charge developers money for it? Or perhaps you had some secret-sauce extras to add to C or C++ to "add value" to monetize your exiting developer base? Please patent your extensions before one of those stinking, long-haired hippy types tried to implement a Free version for gcc.

Oh, you were trolling. Right-oh.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

To the GPL or Free Software Foundation folks, they want to write software that is free as in free speech. You can copy it, and distribute it, but you can't restrict other people's rights to copy it and distribute it.

Uhm, the entire point of GPL is that you can restrict others right to copy it and distribute it.

Re:Looks like they are porting Clang features...

[ljw1004]

the BSD licenses appear to be a failure psychologically. The proponents of BSD-licensed software go apeshit when GPL-licensed software reuses their code, but are ok if the stuff disappears in proprietary forks.

You can see this, for example, with LibreOffice/OpenOffice: every LibreOffice release announcement draws ire from the OpenOffice crowd (well, particularly one OpenOffice developer) because the latter feels their code has been ripped off.

That's okay. I'm a huge proponent of BSD and I'm delighted wherever it goes. I'm not sure which proponents you're referring to, but they might be figments of your own prejudices, and I don't believe that any individual examples of your phenomenon would be representative.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

What's the difference? If you didn't look at the original code, then the chances that your own code will look very much like the invisible implementation are the same

The difference is that since the invisible implementation isn't available to me it is evident that I couldn't have looked at it. In the case where it was available to me someone who doesn't know shit will show up and say that I copied the other project and then I have to defend myself for wanting to make the original project competitive.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

The proponents of BSD-licensed software go apeshit when GPL-licensed software reuses their code

Do you have some links? I've been hearing this for years, but I've never seen it happen.

Use a search engine with the three words (without the quote marks) "libreoffice released rcweir". rcweir is the Apache OpenOffice maintainer or something like that, and he can't really let a LibreOffice release announcement go uncontested.

But he's not the first caught up with this particular licensing scenario like a mouse staring down a snake.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

You can see this, for example, with LibreOffice/OpenOffice: every LibreOffice release announcement draws ire from the OpenOffice crowd (well, particularly one OpenOffice developer) because the latter feels their code has been ripped off.

What? These are both GPL.

No. Apache OpenOffice is released under a permissive Apache style license, similar to the MIT X11 license. That makes the copying one-way (short of code explicitly contributed to both).

Re:Looks like they are porting Clang features...

[Anonymous Coward]

The 2-clause BSD license (which is the one used nowadays) is 7 lines of natural English (excluding the disclaimer) and people still can't understand it...

You can't take BSD code and change it's license.

Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

IIRC a Linux dev though it was possible and did so with an OpenBSD piece of code. Some OpenBSD devs complained and the license was reverted to the original one. End of the "shitstorm."

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Having being open with your changes to something you got the recipe for, for free, imposed on you isn't much of a "restriction". Unless you are an unmitigated, premeditated scumbag, that is.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

But it looks really lame when you talk about exiting new features, and you just copied what Clang had before.

Would you prefer they didn't add a good feature that Clang came up with? "Oh, that sounds neat, but Clang already did it so we will have to think up something novel instead." It is not some TV series trying to have an original plot, it should be about making the tool function as best as they can. If someone else comes up with a neat idea, and they can incorporate it, that should be good news.

Re:Looks like they are porting Clang features...

[gnasher719]

To the GPL or Free Software Foundation folks, they want to write software that is free as in free speech. You can copy it, and distribute it, but you can't restrict other people's rights to copy it and distribute it. Just like I can't hand out a copy of the US Constitution or a speech by Abraham Lincoln and forbid other people from sharing it or publishing a copy. Free as in Freedom of the software

Yes, there is always the "free as in free speech" high horse, but the fact is that (a) you can't legally use GPL licensed code in a BSD project, and (b) when licensed code is moved to a BSD project and modified, you can't legally move the changes back to the BSD project.

So these people's view of "free" is something that I can only call perverted.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Uhm, the entire point of GPL is that you can restrict others right to copy it and distribute it.

Put it in this way: the entire point of GPL is that the code will not stop being copied and distributed

Re:Looks like they are porting Clang features...

[Anonymous Coward]

>That's illegal and once fixed I don't remember anyone complaining

No it isn't. That's the whole fucking point of BSD over GPL. BSD lets a third party use the code and integrate it into their own product and license that product however the fuck they want. GPL requires that they release their product as GPL. This is, in fact, the crux of the whole fucking license war. Please help raise the average IQ of internet posts by throwing all of your computers in the trash and never logging on again.

Re:Looks like they are porting Clang features...

[serviscope_minor]

To the BSD folks, they want to write software that is free as in free beer. You can take it, and do whatever you want with it. Drink it, dump it in the trash, give it to your friends, sell it. Free as in Freedom of the user.

You can do all of those with the GPL, too. The GPL is very hot on Free as in Freedom of the User. As a user you will always have those freedoms and no one can take them away from you.

What the GPL does is restrict the freedom of the distributor slightly.

</license pedantry>

Re:Looks like they are porting Clang features...

[Anonymous Coward]

The proponents of BSD-licensed software go apeshit when GPL-licensed software reuses their code

Do you have some links? I've been hearing this for years, but I've never seen it happen.

Use a search engine with the three words (without the quote marks) "libreoffice released rcweir".

I did. I also searched for "rwweir gpl" and checked the first 10-20 results from DDG and Google.
I didn't see he bitch about licenses once (although he's quite vocal and does bitch about stuff) and he even said he was pleased LO was including stuff from AOO.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Re-licensing code without the consent of the author violates against both licenses. Retain the original license, ask permission of the author, rewrite or get out. At least one of the parents above don't appreciate this.

Re: Looks like they are porting Clang features...

[Anonymous Coward]

Can't speak for the OP but we added an optimization plugin and some error checking plugins to clang. These are internal and not distributed so we the GPL wasn't a direct factor. It was an indirect factor in that GCC's code is intentionally bad to prevent people from trying to bypass the GPL. We could have added our changes to GCC but it would have been a lot more work and would then become a maintainance issue for GCC updates.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

I swear these discussions are at Phoronix level of intelligence.

Is it that hard to read and understand two paragraphs? (Hint: read point 1.)
https://en.wikipedia.org/wiki/Bsd_license#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29

Re: Looks like they are porting Clang features...

[turgid]

It was an indirect factor in that GCC's code is intentionally bad to prevent people from trying to bypass the GPL. We could have added our changes to GCC but it would have been a lot more work and would then become a maintainance issue for GCC updates.

Can you explain? Can you tell us what code in particular is bad and can you show us your patch? I've never looked at GCC internals, but I'd like to know.

Re:Looks like they are porting Clang features...

[cheesybagel]

Actually you can switch licenses if the new license does not conflict with the old license. Since BSD allows basically everything to be done with it you can restrict it any way you wish. Including putting it in proprietary source code.

Re:Looks like they are porting Clang features...

[cheesybagel]

You mean Clang has the Apple PR department.

Re:Looks like they are porting Clang features...

[Gavagai80]

Being open with your changes is all the LGPL requires, but the GPL requires being open about all the unrelated stuff you've done when you integrate a GPL component.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

The following quote is the complete text of the 2-clause BSD license (sans the disclaimer, which doesn't add anything relevant to this discussion). Note that it is this text which determines what is and isn't allowed to do with code using that license. I put the parts relevant for this discussion in bold.

Copyright (c) YEAR, OWNER
All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Re:Looks like they are porting Clang features...

[Wootery]

The 2-clause BSD license (which is the one used nowadays) is 7 lines of natural English (excluding the disclaimer) and people still can't understand it...

You can't take BSD code and change it's license.

It's ironic that you're laughing at those who misunderstand the licence, given that you've fundamentally midunderstood the licence.

If your interpretation were correct, it would be functionally comparable to the GPL, and we wouldn't have all those flame-wars.

It's a 'copycenter' licence, not a copyleft licence. You're allowed to release your fork under your choice of licence, whether proprietary, Free/Open Source, or anywhere in between, provided you don't hide the fact that your software is based upon that original BSD 2-clause licensed software.

It's a little confusing, as "must retain the above copyright notice" can easily be misinterpreted the way you did, to mean "you must release your fork under the BSD 2-clause licence".

Relevant Wikipedia content.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

No you cannot, only the copyright holder can change the license of the original code.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Uhm, the entire point of GPL is that you can restrict others right to copy it and distribute it.

Technically true, but the only restriction is that those others cannot in turn add further restrictions.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

The BSDL code must continue to be licensed under the BSDL. You can add to it and any new code can be licensed under a different license but this does not change the BDSL in any way. Your software can have multiple licenses attached. You can make the source and/or binary proprietary, nothing in the BSDL prevents this. All that is required is to follow the documentation requirements in the BSDL.

This is, in fact, the crux of the whole fucking license war. Please help raise the average IQ of internet posts by throwing all of your computers in the trash and never logging on again.

Take your own advice.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Actually, I am pretty sure that re-licensing BSD as GPL is perfectly in-line, as the BSD license allows re-use with attribution.

GPL also requires attribution, and thus is a valid license to move GPL to, so is closed source (with attribution).

Now, that we have established its legality, we can properly debate its dickishness.

Re:Looks like they are porting Clang features...

[Anonymous Coward]

You are re-stating the original argument about free software that has been done to death on the internet.

To the BSD folks, they want to write software that is free as in free beer. You can take it, and do whatever you want with it. Drink it, dump it in the trash, give it to your friends, sell it. Free as in Freedom of the user

Your first sentance does not correlate with the second or third sentence. The term "Free Beer" means 0 cost. 0 cost, is not necessarily what either BSD or GPL is about at all. The term you are looking for is "Free Libre" as in freedom to 'do whatever you want with it.'

Even though your terms are mixed, we still all got the idea... just thought I'd inform you to save you from future embarasment.

In terms of BSD vs GPL, you can think of GPL as "Mostly free, you're free to do what you want so long as you do not restrict the freedom of others and you do not plagerise." BSD you can think of this way "Almost totally free, you are free do to what you want, including the freedom to restrict the freedom of others, but you cannot plagerise."

Re:Looks like they are porting Clang features...

[Anonymous Coward]

Be careful what you mean by "conflict"; the usual meaning, under which BSD is compatible with GPL, is "I can distribute source code and binaries derived from both licenses". This is confusing because licenses like the MPL have explicit clauses for re-licensing.

Re:Looks like they are porting Clang features...

[BitterOak]

To the GPL or Free Software Foundation folks, they want to write software that is free as in free speech. You can copy it, and distribute it, but you can't restrict other people's rights to copy it and distribute it. Just like I can't hand out a copy of the US Constitution or a speech by Abraham Lincoln and forbid other people from sharing it or publishing a copy. Free as in Freedom of the software

Actually, since both the US Constitution Lincoln's speeches are now out of copyright, you can use them verbatim in a larger work, such as a novel, and restrict further copying/distribution of that novel. That's exactly how BSD licensed software works, but not GPL. If the Constitution were licensed like the GPL, and I quoted it in a novel (assuming the quote were long enough to not be covered by the fair use exemption) then I would have to release my entire novel under the GPL as well. So your example really doesn't support your argument, but rather the opposite.

Re:Looks like they are porting Clang features...

[david_thornley]

You can't change the license.

What you can do is release what you're working on under another license in addition to BSD. If you've used GPLed code, say, the total has to be GPLed. Parts of it now are under both licenses, and (if I can pick them out) I can use the BSD code under the BSD.

Re:Looks like they are porting Clang features...

[olau]

(a) you can't legally use GPL licensed code in a BSD project

Yes, you can. You just can't keep licensing the result as BSD, because that would circumvent the GPL license - someone could take the BSD-licensed result and put it into a proprietary code base, something that people licensing their works under the GPL are not okay with.

But I'll grant that you that these days, it would perhaps be a good idea if you could keep the result licensed under two licenses, so the GPL-part under GPL and the rest under BSD. As long as the rest of the project is under a GPL-compatible free license, I don't really see the problem.

Of course, that could quickly turn into a mess. May not be workable in practice.

Re:Looks like they are porting Clang features...

[Bengie]

OpenOffice != Apache OpenOffice

Re:Looks like they are porting Clang features...

[dkf]

Uhm, the entire point of GPL is that you can restrict others right to copy it and distribute it.

Technically true, but the only restriction is that those others cannot in turn add further restrictions.

Practically, the way people actually tend to view GPL is as "you can't build your own custom commercial software on top of it". Whether this is true in fact doesn't matter; it's what they think. The BSD license really just says that you can't claim you wrote what you didn't, and you can't change the license; it definitely permits building proprietary things on top. (You could just take the software itself and sell it, but since others could provide the same thing for nothing, there'd be no value-add in doing so; successful products need a USP.)

Re:Looks like they are porting Clang features...

[Wootery]

You can't change the license.

What you can do is release what you're working on under another license in addition to BSD.

No. This is totally false.

Copycenter licences are not viral, that's the whole point. It's almost the same as (but not quite the same as) releasing into the public domain.

I urge you to read up on copycenter licences, and stop spreading falsities. The introductory segment of the Wikipedia article covers this stuff.

(I thought you were going to say "You can't change the license of the original software, but you can use any licence you wish for your fork", which would have been technically correct. I could take FreeBSD, make some tiny changes (or perhaps none at all, I'm not certain on that) and release it as a proprietary OS called WooteryBSD. This doesn't mean I have the power to change the licence of FreeBSD itself, of course.)

Re:Looks like they are porting Clang features...

[DuckDodgers]

You can't use BSD license code in a GPL project, either, so I don't see how that makes BSD any better.

Re:Looks like they are porting Clang features...

[DuckDodgers]

Thanks for pointing out the flaws in my analogy. (To be clear, that was not sarcasm.)

Re:Looks like they are porting Clang features...

[DuckDodgers]

I don't think you can use GPL code in a BSD project. The BSD license states that redistribution of the software in source or binary form must include the BSD license. The BSD license includes a clause allowing redistribution of the software in binary form without guaranteed access to source code. So if you put GPL code into your BSD project, the resulting project is GPL software that can be distributed in binary form without guaranteed access to the source code, which violates the GPL.

So you can neither go GPL to BSD nor BSD to GPL, not directly. You have to reverse engineer the software you want to use and re-implement it.

Re:Looks like they are porting Clang features...

[david_thornley]

I read the article, and it didn't seem to me to contradict anything I said.

As far as I know, you can't change the license. You can add other licenses on top, if they're compatible (and darn little is incompatible with BSD), but the BSD license still applies to the BSD-licensed code, and you cannot remove the attribution or license.

If you fork, you can add pretty much any other license to what you release, and what you release will be under that license. The fact that some of the code is still BSD-licensed doesn't mean anything else is, and so it's easy to take BSD code and incorporate it into proprietary software, with pretty well whatever additional license you want. The stuff that was BSD is still BSD, but you don't have to make it possible to take it out of your product. The fact that it's not viral like the GPL means you can slap additional limitations onto your product, since you have the copyright on the derived work, just as somebody else has copyright on the BSD stuff.

Therefore, yes, you can take FreeBSD and make a proprietary WooteryBSD under any license you want (as long as it's compatible with BSD). You cannot legally remove the BSD notices, since you need to use FreeBSD under its license terms and those require the notices.

Re:Looks like they are porting Clang features...

[Wootery]

I think maybe you do understand the BSD licence. When you put What you can do is release what you're working on under another license in addition to BSD you gave me the impression that you thought that if I fork a BSD project, my work must be released under BSD, perhaps bi-licensed with something else. I think you meant What you can do is release what you're working on under another license, but you still have to bundle the BSD licence text to fulfill the BSD licence still applying to the original BSD-licensed portion, which seems about right, but practically speaking counts for very little (as you say, it doesn't require that the BSD components be retrievable).

It's this requirement which makes it different from WTFPL/Unlicence/public domain.

darn little is incompatible with BSD

Indeed, assuming it's not the very old BSD licence. If it's the old BSD licence with the 'obnoxious advertising clause' in it, then it's not GPL compatible.

Gets me thinking.... they say recent versions of the BSD licence are GPL compatible. I wonder how. GPL allows one to make no mention of the BSD licence...

But but Google?

[iYk6]

But then how would Googlebot know that Phoronix is really great and popular and they should rank it higher in searches?

Re:But but Google?

[Anonymous Coward]

Is this news about how GCC 4.9 is great or how about Phoronix is popular?

Re:But but Google?

[Anonymous Coward]

Yes!

Re:But but Google?

[Anonymous Coward]

Also, Phoronix just sounds funny, so there's that as well!

Finish C++11 support first?

[joncombe]

I see from the status page the Regex support is still not complete, part of the C++11 standard. It would be nice if support for this standard could be completed before starting on C++14.

Re:Finish C++11 support first?

[dremon]

Their status html docs aren't updated yet to reflect the actual status. Look at the gcc/libstdc++-v3/doc/xml/manual/status_cxx2011.xml file for the up to date information (or the gcc/libstdc++-v3/ChangeLog for technical revision history).

Re:Finish C++11 support first?

[Rockoon]

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems. - Jamie Zawinski, 1997

Re:Finish C++11 support first?

[Anonymous Coward]

14 is a bug fix release. You don't need to support every library in C++11, before you fix existing things.

Re:Finish C++11 support first?

[DuckDodgers]

In open source software as in proprietary, often the out-of-date component of the project is the documentation.

Re:Finish C++11 support first?

[Anonymous Coward]

There are apparently some juicy bits in the C++14 that are more sought after than the completion of C++11.

Re:Finish C++11 support first?

[game kid]

Supported or not, <regex> may yield surprising results when used with UTF-8 or other Unicode text, so those may require a non-<regex> library or the proposed <unicode> header for C++14 anyway.

Re:Finish C++11 support first?

[Anonymous Coward]

I agree. Lack of Regex has been a real pain.

Re:Finish C++11 support first?

[spitzak]

Actually the behavior of regex on UTF-8 is probably desirable.

Suggestions that "*" mean any number of repeats of make as much sense as suggesting that "the*" means the user wants any number of repeats of "the" (rather than the 'e') because "the" is an English word. It adds hugely to complexity of regexp for no actual gain except for idiots who think the codeunits are actually an item you want to manipulate because you are totally unaware of non-European languages. You should be manipulating words of variable length.

Personally I am glad that C++11 regexp works this way because it will stop the idiots who are trying to match "code units" and think changing capitalization can be done in-place and other 1960's concepts, and it might, just maybe, start to fix I18N.

(It may be useful to have ranges aware of UTF-8, but at a very very low level. A syntax for ranges of substrings may be useful, ie something like [{abc}-{abf}] matches abc, abd, abe, abf, and valid UTF-8 sequences cause this automatically. The reason is that I think it will get the most useful effect of "understanding UTF-8", and that any range that accidentally contains valid UTF-8 could be rearranged into one that does not. This will still require a rule for what is "valid UTF-8" to be defined and never ever changed even if the Unicode definition changes.

Re:Finish C++11 support first?

[spitzak]

Damn slashdot ate my angle brackets:

Suggestions that "<codeunit>*" mean any number of repeats of make as much sense as suggesting that "the*" means the user wants any number of repeats of "the" (rather than the 'e') because "the" is an English word.

Re:Finish C++11 support first?

[GiganticLyingMouth]

It would be nice to have regex support, but I wouldn't want them to halt their entire development pipeline to implement it. If they had to finish implementing the previous standard before starting on the next one, we would still be on C++03 on account of exported templates.

Re:Finish C++11 support first?

[spitzak]

That "proposed standard" is very very bad. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3572.html

It does not support decoding UTF-8 in an error-preserving way, and appears to also remove the ability to default character strings to UTF-8.

These are complete job-stopping bugs. Though if the intention was to try to save all the misguided investment in "wide characters" by making it as hard as possible to use UTF-8, it is a good attempt, and I suspect that is the underlying reason for this.

Re:Finish C++11 support first?

[dkf]

Suggestions that "<codeunit>*" mean any number of repeats of make as much sense as suggesting that "the*" means the user wants any number of repeats of "the" (rather than the 'e') because "the" is an English word.

Do you mean bytes or characters? While you think these are the same thing, you'll continue to be very confused.

Re:Finish C++11 support first?

[spitzak]

I meant code point, not code unit. Ie what you are calling a "character". I typed the wrong thing there which does not help. You are correct that people thinking they can work in code points rather than bytes (or words for UTF-16) are a huge problem and why Unicode is not working yet. I consider anybody who thinks Unicode requires more than 8-bit code units to be in this category. A further problem is that a lot of people think the code points are "characters", which is actually an undefined entity in Unicode.

More carefully, and putting the full incorrect assumptions in, there are people who think that a regex of "<character>*" means that the character should be repeated 0 or more times, when in fact it should mean that the last code unit of the character should be repeated 0 or more times. This may seem obviously wrong in UTF-8, but it is equally wrong even in UTF-32 (because of combining characters). Actually fixing this would require regex to understand the entire Unicode definition, which is hugely complex, changing over time, and this has the perverse effect that you can no longer use regex to accurately manage Unicode encodings since you can no longer deal with the code units.

The regex "(<character>)*" does what is wanted for all representations and allows the user to decide exactly what is a "character". I don't think the burden of putting two parenthesis in there is that bad, really.

Therefore the C++11 regex is doing the correct thing by being the simplest possible that does valid operations.

(I think it *may* be useful to have the regex ranges understand UTF-8, provided it is always possible to rearrange your ranges to not trigger the UTF-8 matching and thus do ranges of code units. This has to be VERY carefully decided on, and the rules for how it matches UTF-8 have to be very well defined and are not allowed to ever change even if Unicode changes the UTF-8 rules).

Huh?

[Anonymous Coward]

Steve... is that you? Are you alive?

nds32

[Anonymous Coward]

Is that another arm SOC or something else?

Re:nds32

[Narishma]

No, it has nothing to do with ARM. It's a different architecture: http://www.emdebian.org/~zumbi/mx53/u-boot-imx/doc/README.NDS32

And then there's this:

[golodh]

How about notifying us when it's actually there? I get a bit antsy about newsflashes like this ("we're planning to release version X and if all goes well it will totally prod buttock").

I'm not particularly interested in what people (GCC in this case) say they'll (probably) include in the next release.

Why not wait until they've actually released the new version and we have something to test? Or better yet, someone has done the tests for us and is writing about the results.

Re:And then there's this:

[serviscope_minor]

How about notifying us when it's actually there?

Oh wait, a large amount of it is:

http://gcc.gnu.org/gcc-4.9/changes.html

Why not wait until they've actually released the new version and we have something to test?

It's released under something called the GPL, by an organisation called the FSF. You may have heard of them. They have things called "repositories" running a system called "SVN" which runs over the "internet".

Apparently you can "download" stuff from these repositories, compile it and run it right now.

It's not a commercial compiler and doesn't do press releases. This is all cutting edge stuff which is being worked on now, much of which is scheduled to be merged into the mainline before release.

Re:And then there's this:

[Anonymous Coward]

Just let us know where 4.9 is in those 'repositories', please.

Without the arrogant stupidity.

Re:And then there's this:

[serviscope_minor]

Just let us know where 4.9 is in those 'repositories', please.

let me google that for you.

Without the arrogant stupidity.

Why? It's a link near the top of the the main project page, which is a simple google search away. Not knowing is pure lazyness. And complaining that it's not available is really dumb.

Re:And then there's this:

[Anonymous Coward]

How about notifying us when it's actually there? I get a bit antsy about newsflashes like this ("we're planning to release version X and if all goes well it will totally prod buttock").

A sad bride, married to a software engineer, showed up at the minister's rectory six months after the wedding.

"What seems to be the problem, my child?" asked the minister.

"Reverend, I like Eddie, he's a good husband and provides everything I need, but I'd like to have children and we've never had relations."

"But I remember the two of you went on your honeymoon. Didn't you have a chance to, uh, consummate the relationship?"

"Well, we spent a week on the beach. The days were fabulous. Then each night, Eddie would sit on the edge of the bed telling me how great it was going to be."

Regular expressions (Atwood)

[dwheeler]

It's funny, but out of context. See: Jeff Atwood, “Regular Expressions: Now You Have Two Problems” June 27, 2008, http://www.codinghorror.com/blog/2008/06/regular-expressions-now-you-have-two-problems.html

Re:Regular expressions (Atwood)

[ttucker]

It's funny, but out of context. See: Jeff Atwood, “Regular Expressions: Now You Have Two Problems” June 27, 2008, http://www.codinghorror.com/blog/2008/06/regular-expressions-now-you-have-two-problems.html

Some people like to guide their coding decisions using sound bytes, don't ruin that for them with your pesky rational arguments and facts!

no news for gccgo

[FithisUX]

and no gdc integration. These are the items I am most interested about.

Half-baked

[golodh]

@ serviscope_minor

You might have heard about the difference between software that's "done" and software that's "work-in-progress" (or "half-baked" to use a less charitable term).

As a compiler *user* (as opposed to a compiler hobbyist) I'm not in the least interested in any work-in-progress in-the-repository stuff because I don't want to waste my time stumbling into all the bugs. So until and unless the GCC is officially released as 4.9, it doesn't exist for me.

I'm perfectly aware that GCC isn't a commercial product, which is all the more reason to stay away from "cutting edge" stuff. I'm happy to let 'em work on that and I'll take a look at it after it's done (and others have verified that this particular cutting edge stuff actually cuts the mustard, so to speak).

Good of you to note that GCC doesn't do press-releases. Only the kind of article that Phoronix published looks for all the world like a press-release to me. Phoronix however is Phoronix ... geek territory with people avidly lapping up the latest new year's resolutions on part of tool makers. It's a specialist audience.

Only ... echoing such articles on Slashdot suggests that it has some news value to a more general audience. Unfortunately that's not the case with half-baked stuff like this it's-in-the-repositories code. If it were done, it wouldn't be "in-the-repository", ok? It would have been *released*.

Re:Half-baked

[lgw]

So what you're saying is, this /. article is for people geekier than you? That's a good thing then, we need more intense geekiness and less US politics.

Re:Half-baked

[Darinbob]

On the other hand, when Clang lists plans one what they're adding in the next version suddenly lots of fans are hopping up and down with joy (and yes they have preliminary release notes for 3.4).

The rule of thumb basically is that product-you-don't-care-about needs to shut up and product-you-admire needs to keep raining down news on the believers.

Does GCC...

[Anonymous Coward]

...still confuse MOVAPS and MOVUPS leading to memory alignment crashes? It's been doing this since 2007.

RedHat Enterprise Linux

[Anonymous Coward]

Wow, this looks awesome. I'm so excited for RedHat to incorporate this version of gcc into RedHat Enterprise in 2032.

GCJ vs. JIT

[codealot]

A good JIT actually performs very well compared to ahead of time compiling, and can take advantage of execution profiling (for things like branch prediction) by deferring compilation until the bytecode runs a few times.

The main advantages of gcj are improved startup times, porting to unusual architectures, and maybe for memory constrained targets.

When comparing C++ performance to Java, there are many things to keep in mind aside from the JIT compiler:

- Java also has GC overhead. You get a fairer comparison by adding garbage collection to your C++ app. The performance effects of garbage collection are complicated, but one of the difficult problems is that it tends to fill the processor data cache with useless entries.
- Java adds overhead required by the JLS such as array bounds checking or class initialization tests.
- Exception handling can also impact code generation. Java requires null pointer dereferencing (for example) to be trapped and handled, which adds abnormal edges to a CFG which places restrictions on e.g. instruction scheduling. Strict expression evaluation order, required by the JLS, has the same effect.
- Java has a more limited type system. In particular objects other than primitive types cannot be passed by value, which tends to result in more frequent memory allocations, more garbage collection, and more pressure on the memory cache than languages that can make more efficient use of the stack.

The biggest reason worked stopped on gcj was the release of OpenJDK, since one of the main reasons for gcj in the first place was to have a fast and free Java runtime. OpenJDK satisfies both.

Re:GCJ vs. JIT

[Anonymous Coward]

1) "A good JIT actually performs very well compared" in theory. FTFY. We're about XX years before JIT'd languages can _reliably_ be as performant as C code in general application.

2) A full-blown JIT without garbage collection is actually pretty hard, so in practical sense you can't have JIT without a garbage collector. The JIT needs to understand the memory model and manipulate object lifetimes in a generic manner unrelated to the contextual semantics of the application, and the only practical way to do this is with a GC. So it's a little disingenuous to say that Java is slow because of GC. Without GC it wouldn't be JIT'd to begin with.

3) Array bounds checking isn't that big of a deal, nor is NULL checking. All good C code does it just as much Java does it. And this is one area where in practice JIT'd applications are reliably good at optimizing where it matters.

4) C applications don't usually copy by value, either, for compound objects. C++ used to do it a ton, but it was slow as heck, which is why recent changes regarding the move constructor were so important.

Ultimately, Java is slower and more of a resource hog because of limitations in the state-of-the-art. Yes, a _ton_ of genius has been put into making Java (and JavaScript, for that matter) incredibly fast. But at the end of the day it's easy to write well written C code which will blow well written Java code out of the water.
But it's all relative. Java is still within an order of magnitude of the performance of C, so it's all kind of pointless, anyhow. No need to be apologist about it. I use C principally, but also Lua and Perl. Lua uses a mark+sweep GC, and so just like Java there you have to be careful about stalling. Perl still uses reference counting, which is actually really helpful in many scenarios, although Perl itself is dog slow compared to Lua, let alone LuaJIT, Java, or C.

Re:GCJ vs. JIT

[Anonymous Coward]

A good JIT actually performs very well compared to ahead of time compiling, and can take advantage of execution profiling

Quite a bit of the overhead required by the JLS could be eliminated by an ahead of time compiler, a normal Java program however cannot be optimized ahead of time as compilation dependencies between class files are defined in a way that makes specialized code paths and inlining impossible, they are also unable to express most other optimisations. GCJ is afaik not limited by the class specification and could inline, stack-allocate, specialize and remove dead code to a great degree.

You get a fairer comparison

Considering adding a GC to c++ for a comparison to Java is not fair at all as c++ as a language was not designed to support a GC (c++11 merely allows a GC as an after thought) and any available c++ GC is a joke compared to extensively fine tuned Java GC.

Java adds overhead required by the JLS such as array bounds checking

Most of this gets optimized out when it can be guaranteed that index is less than array.length, which in a large amount of uses is the case. In many other cases it can be moved to a single check in front of the loop.

class initialization tests.

Classes are fun in c++ too, you get things like virtual calls in the constructor which requires the object to evolve with each finished base class Ctor - in java this simply results in the latest defined overwriting method and default values in the uninitialized fields. Or did you mean a check wether a class is initialized? It would be more or less irrelevant to performance overall as it is a one of cost and the remaining cost is apparently small enough that class initialisation is used as a replacement for double checked locking.

Java has a more limited type system. In particular objects other than primitive types cannot be passed by value,

I don't know if it has been since Java 5 or Java 6 but lots of work has been done to perform escape analysis and do stack allocation of objects when possible. It still wont give you a hyper fast ray tracer if you constantly create new Ray() however :(.

The biggest reason worked stopped on gcj was the release of OpenJDK

Before that it was only not quite dead.

gcj in the first place was to have a fast and free Java runtime

/abused enduser rant/ I thought the reason was to spread the "java is slow" myth and make sure there was at least one implementation of the spec that would break the write once run anywhere guarantee (incomplete impl. AND their own custom C API). Till today I cannot understand why anyone would make apt packages directly depend on gcj instead of the generic java package, running the pre packaged eclipse under Debian was insane (and it took me a week to find out why it was even slower than on windows). Even a fanatic should have noticed that gcj was not adequate for something requiring a high amount of interactivity - I had anti virus software on windows that left me more productive than that./end rant/

GCJ lacked a lot of work, I find it sad that it never reached a quality that I could use without getting annoyed.

Re:GCJ vs. JIT

[codealot]

1) Sure. When I said "performs very well" I mean within an order of magnitude. I've heard claims that JIT technology will surpass ahead-of-time compilation. I don't quite believe that either, and at any rate it's clearly not there yet. I didn't claim the JIT was equally fast or faster, but it's close enough that there just wasn't a ton of people interested in using a compiler like gcj.

2) I'm skeptical that JIT requires a GC (in the general case, though for Java it is clearly required by the JVM). Do you have a reference for this claim?

3) Yes, and of course real Java code does bounds checking too. Back when I was using gcj extensively, I was finding examples of duplicate array bounds checks, one added by the developer and one inserted by the compiler. A good compiler should be able to eliminate the redundant check. At times this is hard, such as when the caller does the bounds checking, and does so in a different translation unit.

4) Interesting. There are examples, such as the complex type, that would be far more efficient as a value object. But I agree with your point that passing objects that are too large as value objects is probably counter-productive.

Mostly I agree with your points. Especially that Perl is dog slow.

Re:GCJ vs. JIT

[HiThere]

Sorry, but work on gcj was slow for a long time before Java was partially GPL'd. My take is that the people who write compilers for native code aren't really interested in languages designed for an interpreter. (Yes, they call it a virtual machine, but to me that's one flavor of interpreter.)

My (current) biggest complaint about Java is that it doesn't implement structs, i.e., non-object containers for non-object data. Perhaps I just don't know the language, but it appears to be that I need to copy data three times on the way to writing it to a fixed-block random access file. And another three times to read it back in.

A secondary complaint is the way it handles unicode. I can see the reason and justification for either utf-8 or utf-32, but I can't see utf-16 (UCC2?) (N.B.: I'm not very happy with how C/C++ handles that either, but saying "use a library" is at least understandable. I much prefer Vala's approach...now if it would just get documented...)

FWIW, I much prefer Python, Ruby, or D to any of the gcc languages. but if I had to choose one of them I'd choose Ada (which is also being upgraded). Ada's a bit overcontrolling, which makes handling character string of differing lengths a problem, but it avoids a lot of the problems inherent in the basic design of C that were inherited by C++. (Sanitizing undefined behavior helps a lot, but it's not sufficient. Some things, like pointer arithmetic, are well defined, but just dangerous. And stupid when there's any compiler optimization happening at all. [Yeah, it used to be a way to do variable length arrays. And that was a bad idea at the time. Allocate the largest array that you're going to allow, and only write what you need. You need to keep track of the size anyway.])

P.S.: While I understand that much C/C++ syntax is driven by prior choices, much of this new syntax is UGLY. That's been a problem ever since templates started appearing, but it's gotten worse with every addition. At some point they need to do a de novo redefinition of syntax, and define an isomorphism between the two syntaxes. Then a compiler switch can alternate between syntaxes until the current version can be deprecated. I'm starting to think that APL had a better design than modern C++, and that was BAD. Now, in addition to << >> they've got [[ ]], and I guess next will be (( )) (unless that's already in use somewhere).

P.P.S.: Please note that all of my favorite languages are like Java in that they have built-in garbage collectors. This implies some design choices for the language, especially that integers and pointers are NOT interconvertable. I know that there is (at least one) C garbage collector, but because of language design it needs to work rediculously hard. But garbage collectors make it easy to deal with strings of variable and unknown length. This is important. (Yes, there are ways to deal with them without a garbage collector, but they are clumsy and ad hoc.) Language design is strongly influenced by the presence or absence of a garbage collector. It's not, however, a requirement that the garbage collector always be active. And for most programs in well designed languages, having the garbage collector active does not slow things down markedly. (Naturally, real-time applications won't want to have an active garbage collector most of the time, but even many of them can benefit from a garbage collector that can be invoked at predefined times.)

Re:GCJ vs. JIT

[leaen]

P.S.: While I understand that much C/C++ syntax is driven by prior choices, much of this new syntax is UGLY. That's been a problem ever since templates started appearing, but it's gotten worse with every addition. At some point they need to do a de novo redefinition of syntax, and define an isomorphism between the two syntaxes. Then a compiler switch can alternate between syntaxes until the current version can be deprecated. I'm starting to think that APL had a better design than modern C++, and that was BAD. Now, in addition to > they've got [[ ]], and I guess next will be (( )) (unless that's already in use somewhere).

Yes, (( )) is used in attributes. Also ({ }) is used to convert compound statement into expression. You are left with {{ and {( and when these will be taken we start to use {) (}.

Re:GCJ vs. JIT

[bored]

I'm skeptical that JIT requires a GC (in the general case, though for Java it is clearly required by the JVM). Do you have a reference for this claim?

Well, to point to evidence otherwise, if by JIT your taking about dynamic translation/recompilation for optimization purposes then no. A number of machine emulators (CPU->CPU, see apple Rosetta) perform dynamic translation, and in a number of cases pretty advanced optimization. There have also been a number of native dynamic translators for a given machine architecture see (http://www.hpl.hp.com/techreports/1999/HPL-1999-78.html) for one example. There are also strange hybrids like the Intel Profile Guided Optimizations, where the feedback from a particular run is used to statically recompile the code. This effectively removes the profile/recompile overhead from an application at the expense of the fact that its now statically optimized for a particular kind of dataset.

But, you ask why isn't a JIT part of most compiler packages if it gives you all these advantages. And the answer is three fold. First OOO CPU's kill the majority of the advantage that projects like dynamo found. Secondly, the overhead of the dynamic translation monitoring/recompile is often greater than the performance gain. And finally, the JIT advantages are often isolated to small hot pieces of code (compared with optimizing an application that is hundreds of MB of code). Applications with small performance critical functions are often hand optimized in C/C++ languages in ways that cannot be done by simple dynamic optimization and often yield functions that execute at the maximum a particular piece of hardware is capable of (say limited by memory bandwidth, functional unit throughput, etc).

Re:GCJ vs. JIT

[Anonymous Coward]

... be as performant as ...

Save the syllables! Perform as well as.

Re:GCJ vs. JIT

[codealot]

Thanks. When you say:

Well, to point to evidence otherwise, if by JIT your taking about dynamic translation/recompilation for optimization purposes then no

That is the definition of a JIT I have always used, thus my confusion. All of the reasons you state are performance arguments against JIT, but there are other reasons for JIT compilation, including architecture independence. But since all the world's an x86 these days, that feels less important now than it did 15+ years ago.

Speaking of dynamic recompilation, back in 1998 or so I was running Windows NT on a Digital Alpha. Since there were few native apps, Digital included a translator to run Windows apps (Office etc.) compiled for x86 natively on Alpha, and I'm sure it was some sort of JIT. Those apps would run slowly the first time, but get noticeably faster the next 2-3 times they run. And it legitimately translated and ran the apps faster than a good Pentium Pro machine of the day. That was due to an edge that Alpha had over Intel, rather than software, but the hardware advantage didn't last long.

Re:GCJ vs. JIT

[real-modo]

Save the syllables!

Yeah! Those evil Japanese and Russian syllabling fleets, sweeping the oceans clean of cute baby syllables with their nets and harpoons. We've got to do something!

Write up needs more links.

[plopez]

Please edit and re-submit.

The Antiviral License

[Anonymous Coward]

If you don't want to have your code relicensed under different licenses, use a Copyleft license. If you want to have your code relicensed under different licenses, stop complaining when somebody actually does exactly that.

Actually, I'm not sure they want their code relicensed. Indeed, the BSD license doesn't grant you permission to do so. Theoretically the only reason it works is because the GPL only requires that the code be released under the GPL license but it doesn't require that the original license disappear, it simply demands that the original license can only invoke certain restrictions, like the attribution requirements present in many BSD licenses.

I solved the problem for myself by creating my own license which forbids relicensing but otherwise has no requirements whatsoever. BSD projects can use my code simply by keeping my code under my license and their code under whatever license they choose, as there's nothing about copyright law that requires all of the code in a project to be released under only one license. GPL projects, however, cannot use my code, because the GPL requires all code in a project to be GPL code, but the license of my code cannot be changed. It's really quite amusing since my license isn't specifically GPL-incompatible, but rather, it's the GPL's own viral provisions that create the incompatibility. If they ever create a non-viral GPL it'll automatically be compatible with my license, and if there are any other viral licenses I don't know about, they're automatically incompatible with my license.

Thank you, Clang

[Urkki]

Clang has really become a boon to open source compiler development. Unlike the open source *BSD operating systems, which are too far behind the GPL operating systems in many measures (not all), Clang has really electrified the compiler scene.

I see nothing but good things coming from this in near future.

And in such a rapidly evolving area as compiler development, having a *BSD license does not really hurt either. It's not like the *compiler* is likely to get put into some device with proprietary modifications.

Plans aren't news.

[golodh]

Plans are plans, and primarily interesting to incrowd and fanbois.

News is (mostly) about what actually happened.

Let's not confuse the two

Its simple

[Anonymous Coward]

GPL is about maximizing software freedoms for the end users. You can't take GPL'd code (which guarantees certain freedoms to users, such as the availability of source) and make it into a closed-source product, thus taking away those freedoms.

BSD is about maximum freedom for developers. It gives them code, no strings attached, that they can take and use for something else, even in a closed-source product, with no obligation to give anything back. Thats pretty convenient, especially for closed-source developers.

But the BSD style has two pernicious effects: (1) they sometimes take open-source code and use it as part of a closed-source product without extending to the end users of that product the freedoms that the original open-source code had (i.e. they don't give away the source code, and users who have a bug or a problem with it or still need it after it gets End-of-Life'd are just shit outa luck). (2) Developers who take and use BSD code have no legal obligation to give their modifications back to the community, so sometimes they don't. And that reduces the incentive for others to volunteer their time and effort on those projects. Many people do anyway; but not as many as GPL'd project. For a developer volunteering on a GPL'd project, part of the quid-pro-quo is that they know that anyone else who wants to distribute modified copies or derivative works of that developer's contributions, will have to contribute back their own contributions to the community.

Lots of volunteers like that knowledge that others can't (legally at least) just take their GPL'd code and use it to make a profit in a non-free product without giving anything back to the community. Then again, there's some developers who just want someone, anyone, to be able to do something useful with their stuff. And they don't care if those people make a profit off it. Those developers often choose a BSD-style license to maximize the number of other developers who might be able to do something useful with their code (i.e. because it can be used by lots of developers who are unwilling or unable to abide by the GPL license terms to contribute back their modifications).

I think both styles of license have their place and many important projects exist that could only have been as successful as they were under one model or the other. As a closed-source developer, I sometimes find available BSD-licensed libraries to be extremely useful, in situations where I would not be able to accept the license terms for GPL-licensed libraries. At the same time there is a large and important body of GPL'd software and I'm glad that exists too.